[Standards-JIG] UPDATED: JEP-0136 (Message Archiving)

[Ian Paterson]

Olivier Goffart wrote:
> the save='...' option in the <pref/> should be only for auto-logging.
> client-logging has his client specific option in the client config file.
>   
Remko Troncon wrote:
> I'm wondering why archiving preferences should also apply to local archiving,
> and if this doesn't complicate things. What if your preferences for local
> archiving are different than your preferences for server-side archiving ?
>   
Short factual response:
The protocol does not prevent a client keeping a separate local 
preferences file which overrides the user's preferences kept on the 
server. The following sentence has been added to the working copy of the 
JEP: "A client MAY maintain a set of preferences in a local file which 
takes precedence over the preferences stored on the server for both 
local archiving and manual archiving."


Long opinionated response (only if you're interested enough):

Olivier Goffart wrote:
> the save='...' option in the <pref/> should be only for auto-logging.
> client-logging has his client specific option in the client config file.
>   
Web clients can have no local config file. When e2e encryption is 
enabled Web clients must use client-logging (manual not auto archiving).

Also some people already use several clients (home, work, web and 
mobile) and occasionally upgrade to new clients as better ones are 
released. They don't want to have to set up their (local) archiving 
preferences for every client they use, and to manually synchronize them 
on every client whenever their preferences change!

Remko Troncon wrote:
> I'm wondering why archiving preferences should also apply to local archiving,
> and if this doesn't complicate things. What if your preferences for local
> archiving are different than your preferences for server-side archiving ?
>   
I suppose some clients might want to offer such a feature, and local 
preference files will also be useful in cases where a user might want 
client-specific preferences (e.g. where local-archiving is prefered and 
a client machine has only limited local storage space).

However, I suspect that in the majority of cases a user's archiving 
preferences would be the same for different clients and for different 
archiving methods, and that in an effort to keep their interfaces 
simple, most clients won't even offer separate sets of archiving 
preferences to users. Server-hosted preferences make sense even for 
local archiving (see the multi-client advantage above).

The killer feature offered by JEP-0136 to the users of desktop clients 
is that they can retrieve all their chats on any client machine (even 
chats that took place on different client machines). IMHO, a smaller, 
but worthwhile, benefit is having just one set of archiving preferences.

> I wonder how the UI for archiving should work. You don't know the
> user's preferences unless you log in. Clients typically provide a way
> to enable/disable local logging prior to connecting. If you want your
> archiving preferences to apply to local logging as well, the selected
> settings may conflict with the ones you discover after logging in.
> Should you override the locally selected settings ? Should you
> update the server-side settings ?
>   

Hmm, I expect users won't be editing their archiving preferences very 
often, and that would typically occur when they are online anyway. As an 
IM user, I think the only preferences I care about editing when I'm not 
online are the login settings and my invisibility settings. If I've got 
to choose between the two benefits of:

1) editing preferences when I'm offline, and
2) having my preferences automatically replicated between all the 
clients I use (assuming I choose them to be replicated at all)

I'd definitely choose the latter. But other developers may well 
disagree, and since the protocol now makes it clear that clients can 
employ a separate local preferences file, I guess each implementor will 
decide for himself/herself. :-)

- Ian