I think I lost track of the original message that started referencing
the options according to letters :)
I'd like to suggest an end alltogether of all-in-one communication
clients. It may fit a Windows-style mode for use, but it contradicts one
of the more elegant and sensible parts of the Unix philosophy, that
being one application per task.
Anyway what I'm getting at is in order to facilitate simplicity I think
it might be helpful to talk about these things in terms of protocols or
types of delivery that Tails wants to prioritize (rather than using
client examples as the article of dialogue), and then choose a discrete
and simple client for each, which will probably change of course as time
goes by; ideally the protocols Tails supports in one way or another will
not.
Using this perspective, it looks to me as if there are really only a
grand total of four clients needed here: SMTP, XMPP, IRC, and some form
of serverless system.
Is this thought disruptive in a good way or bad? It just doesn't seem
like the hunt for an all-in-one client is going to be a good design
choice in the long run, especially when individual clients can come
relatively cheap size and code-wise.
gl
On 2016-01-27 10:01, intrigeri wrote:
sycamoreone wrote (26 Jan 2016 22:03:00 GMT) :
sajolida:
intrigeri:
I am also for keeping D separately. But the blueprint should document
the use-cases A, B, C, and E that Pidgin and its potential replacement
should address. And also the use-case D that it need not.
Yes. I see that it's been done already (with a new
nomenclature), cool!
> I don't know of any tool that provides D _and_ another one among A,
> B and C. So for the moment, I think that D should be solved separately.
Exactly.
Yes.
I'm glad we agree on dealing with D separatedly.
Cheers!
_______________________________________________
Tails-dev mailing list
[email protected]
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
[email protected].
