Alexander Tsvyashchenko <[email protected]> a écrit :
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
Thanks for having done that :)
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.
ok scope is fine. <auto save='true' scope='permanent'> will do what
current ejabberd module do, so nice.
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.
All that sounds ok!
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.
And sessions may not be corrcetly closed by clients. So I don't think
it's a very good solution. That would leak servers with bad clients.
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?
I'm not sure it's nice because it's not very safe, if conversation
lasts longer and clients don't handle the timeout value, server will
save data that it should not. Server could just check when the
resource of this thread logs off, no?
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.
Indeed I don't think it's usefull. Server should of course remove
those auto things at the end of the stream, and also when contacts
logs off (Can we start a session with an invisible contact? ) Isn't
that enough to clean server settings? Do you think this timeout
attribut is usefull?
--
Yann
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
