Re: [Tails-dev] [tor-dev] [GSoC] Tails Server - status repor…

sajolida:
> segfault:
>> I sent my first GSoC report only to tor-dev and forgot to send it to
>> tails-dev too. I quote it in full at the end of this mail.
>
> I'll answer on tails-dev only and add George in explicit copy to avoid
> crossposting across mailing list.
>
>> sajolida:
>>> segfault:
>>>> * I began implementing the CLI, the current code (not ready for review
>>>> yet) is also available on gitlab [2]
>>>>
>>>> Next I plan to continue the design of the GUI, after others commented on
>>>> the new prototype. There are still some features missing which I will
>>>> implement in time. In parallel I will continue implementing the CLI and
>>>> discussing the design decisions.
>>>
>>> Maybe the call for review for the CLI should be sent to
>>> tails-dev@??? instead of tails-ux@??? :P
>>
>> I didn't send a call for review for the CLI yet. Actually I wrote that
>> it's not ready for review yet (see the quote above).
>
> I understood this and was mainly pointing out, partly as a joke, that
> once it was ready it should be sent to tails-dev and not tails-ux. Sorry
> I was unclear.

Oh, I didn't get that joke :)

>
>>> Also, just out of curiosity, when are you planning to work on "Design an
>>> extensible and robust format describing the services and how they
>>> integrate into Tails"?
>>
>> I think this discussion has already started with anonym's mail [1]. I
>> discussed this further with him in XMPP because I had a different design
>> in mind but I think his is better, so I didn't write a mail about this
>> after the chat. I already started implementing and extending the design
>> (I think most shortcomings only become obvious during implementation).
>> Maybe I should send another mail about this.
>>
>> [1] https://mailman.boum.org/pipermail/tails-dev/2016-March/010506.html
>
> You're right and I actually didn't read this thread very carefully
> myself because it was going out of my department. I was thinking that
> for example it would be good to have a blueprint that specifies how to
> describe a new service (the options specific to this service, what needs
> to be made persistent, how to start and stop it, etc.). And anonym's
> email looks like a good start indeed.
>
> This will be useful during the design phase to allow people other than
> anonym and George to review it. For example, I really want intrigeri to
> review your specification because his vision is usually nicely
> complementary to anonym's but I don't expect him to follow our threads.

Ack.

>
> This blueprint will also be easy to transform into a design document at
> the end of your project for more people to develop services. Because
> you're developing something like an API or a plugin mechanism here and
> this needs to be documented for others to use.

Ack.

>
> That's something we do quite often while working on complex features: we
> elaborate blueprints as working documents and reference for reviews
> during the process, and then we turn them into design document once the
> project is over. And it will also be nicer to you not to have to write
> all this documentation once you delivered and want to go do something
> else more exciting than writing doc.

Ack.

I'm convinced and will start working on a blueprint for the TailsService
and TailsServiceOption designs. :)