Yann, On Sat, 19 Dec 2009 10:18:01 +0100, Yann Leboulanger <[email protected]> wrote:
>>> But a solution could be that when we send a request to removing a >>> collection being recorded by the server (example 48) The server should >>> stop recording this session automatically, don't you think it could be >>> added to the spec? >> >> I think that might cover typical use cases, but might lead to problems in >> some (not really common, though?) scenarios. [skipped] > hmm indeed, in this case I see 2 solutions: > - The solution you propose: closing / reopening > - add 2 new <iq> commands: Stop logging and re-start logging I think the main problem now is not how to manage auto-archiving (using <remove>, <auto>, <item> or whatever else method), but how to define the scope to what this management applies: if we successfully define what "conversation" is exactly for the purposes of auto-archiving, the rest should be trivial - and we might use <auto>/<item>/whatever else then as well to perform full management (not "disable only" like in <remove> approach) as it's not harder at all, but gives complete control. [skipped] >> 2) <auto> setting in current XEP-136 spec applies to stream, it is not >> stored permanently, so its value is lost when stream is re-opened, see >> section 6, after "Otherwise:" words. > > That's not the case in your ejabberd module :) but ok. So client have to That's true, because I thought (and still think in fact) that specification is wrong here as it tries to be on the safe side instead of being on the "usefulness" side ;-) New ejabberd module implements <auto> according to spec, but adds "scope" extension to be able to store it permanently as well. > set auto to true if if save attribute default element if != false. Why > force client doing that? Clients have no way to tell their server to > always do auto-archiving? No, in current spec they don't. I believe it's currently specified in this way for "safety", so that if client knows nothing about XEP-136 and about auto-archiving in particular - it's not possible that conversations are automatically recorded without user knowing about that and being unable to stop that. Personally I disagree with this approach, but that's how things currently are - adding "scope" extension should deal with it in clean way, I hope, because that would be "conscious" decision by the client to make auto-recording permanent then. [skipped] > ok, but in this case I don't see how my client ould implement this XEP. > It supports E2E and GPG, so I don't see how to tell server to not store > those encrypted messages, but store unencrypted messages with those same > contacts. > > Adding the <item> elements is a workaround, not a solution, we agree on > that. > And ok some clients don't support <thread> nor session negotiation, but > in this case they cannot support the OTR negotiation of this XEP, so I > don't see the problem for the server to track those conversations when > <thread> element is present. IMHO that's a good point! I thought about "generic" solution to conversations tracking, but it's true that we're not obliged to do it in that way - we can just specify it so that if clients use <thread> - we provide proper tracking, if not - this functionality is just not available. Then we could just use either <auto> or <item> approach proposed earlier, but instead of attaching this information to JID, we can use 'thread' attribute. Now I tend to thing <auto> would be better, to highlight the difference between persistent <item>'s for JIDs and temporary <auto>'s for 'thread's. If messages sent use the 'thread' value that is present in one of <auto> elements - we use those settings for auto-archiving, if not - we use generic settings. All settings with 'thread' attribute should be discarded when stream is closed. The only (?) remaining problem then is the way to expire these settings while stream is still open. We could require the server to intercept session negotiations and remove these settings when session is closed (as server already has to intercept all messages for the purposes of auto-archiving that should not be a big deal), but that would mean that server should understand XEP-0155 and also would not work for conversations not using XEP-0155 and using <thread> only. Therefore it looks like the better solution would be just to use timeouts for these settings in the way similar to this one: 1. Client sends to the server <auto thread='..' save='false'/> (or save='body', or whatever it needs). 2. Server performs prefs push to all connected clients with something like <auto thread='..' save='false' expire='..' /> where 'expire' means how long the server will keep this temporary setting. We might call it differently, though, to avoid confusion with <item> 'expire' attribute - maybe 'timeout' would be better? It's now the client's responsibility to make sure this setting remains valid during the whole conversation - if it lasts longer than 'expire'/'timeout' value client should renew it before that timeout expires. If client finishes conversation sooner than timeout expires - it can either let it lapse on its own or can reset it explicitly sending smth like <auto thread='..'/>. Additionally, server could perform prefs push on <auto> setting expiration to make it clear this setting is not going to be applied anymore, though I'm not sure that is really needed. What do you think about it? -- Good luck! Alexander
