[Standards-JIG] NEW: Message Archiving

David Yitzchak Cohen lists+jabber_standards at bigfatdave.com
Fri Jun 11 06:48:05 UTC 2004

On Thu, Jun 10, 2004 at 12:00:17AM EDT, Justin Karneges wrote:
> On Wednesday 09 June 2004 7:18 pm, David Yitzchak Cohen wrote:

> > It's easy to argue that iq shouldn't be logged in <fill in the gap with
> > whatever you want>, since it's easy to argue from the XMPP specs that
> > iq shouldn't really be logged at all.  However, if you're going to log
> > every time a guy changes presence in the middle of a chat, you might as
> > well also log iqs that happen during that conversation (since remember,
> > they won't just be silly version requests or basic discos, since those
> > are all done at logon by most clients - in other words, any iq sent
> > during a chat will most likely be directly relevant to that conversation).
> I get what you're saying, but this isn't so cut and dry.  Clients could 
> certainly make those kinds of iq requests during general use.

They _could_, but in practice, what motive would there be for a client to
send a trivial request in the middle of a chat?  I can only think of the
polling case (where you want to find out some sort of information about
the client/user/whatever that may change by simply requesting it every
so often).  There's very little (if anything, really) that falls into
this category currently.  Now, you'll notice that the current trend in
the Jabber world is to move this type of info into presence elements or to
pubsub it (so it arrives as messages, not iqs), so it seems unlikely that
new stuff is going to pop up in this category (since presence or pubsub
are fundamentally better methods, anyway) in the future.  In other words,
it should be quite safe to conclude that iqs received in the middle of
a chat from the guy on the other side of the chat are probably not noise.

> For logging, 
> it would just be a matter of deciding what is interesting vs what is not.  
> I'd say version requests and disco don't fall in line as something worth 
> logging, and so a client can just skip them.

I guess it's really up to the client to decide, then, what's worth logging
and what's not.  If we go that route, you might as well let clients log
anything they want, whether or not it's part of some "message archive."

> > > If we do want to
> > > log other events, for example file transfers, then I think we should have
> > > specific elements for these situations.
> >
> > Just like you log message elements almost verbatim, you can log presence,
> > iq, or virtually any other element almost verbatim.
> The issue with iq is that there are so many kinds of things that you wouldn't 
> want to log, and so it would be a matter of picking and choosing (and even 
> then, this doesn't apply merely to iq.  you wouldn't want to log IBB message 
> packets either. ;-) ).

How about pubsub stuff?

> For example, a File Transfer iq request can end up invoking a SOCKS5 
> Bytestreams iq request, and the latter is not interesting at all.  Even half 
> of the File Transfer iq itself is not interesting...  who needs to log that 
> silly x:data form?  With messages and presence, the client can omit fields.  
> I suppose the same could be done with iq, but iq isn't meant to be malleable 
> like that.

Here's the thing: noboby's asking you to replay the tranactions in 100%
correct XML.  A client tells the logger what to log.  If the client
wants to log only half of a file transfer iq, it's the logger's job to
log just that.  Who cares if iqs aren't really malleable by the specs?
A client should be able to just chop out anything it doesn't like,
and ship the rest off to the logger.

> I still say having a set of high level events would be a better way to go.  

maybe ... it takes lots of flexibility away, though, introducing
the extra complexity of mapping stuff back and forth between our two
representations :-(

> And it wouldn't have to be total reinvention, they could use constructs from 
> the various protocols.  For instance, the File Transfer event could utilize 
> the same <file/> element found in JEP-96, just without the rest of the iq 
> packet.

I dunno ... I'd rather just allow people to log the file element all by
itself if they don't want to log the full iq.  Then again, maybe I'm
actually asking for a totally different JEP - generic XML logging or
something like that. . .

(I admit - I'm biased: my client logs every bit of XML that passes through
it as-is with a timestamped enclosing element, and only organizes stuff
by bare JID into presence, message, iq, and roster item "collections."
(My assumption has always been that logging is better than not logging.
You can always delete the logs (or parts of them) if you find 'em boring,
but you can't create them from thin air if you need 'em suddenly. . .))

 - Dave

Uncle Cosmo, why do they call this a word processor?
It's simple, Skyler.  You've seen what food processors do to food, right?

Please visit this link:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20040611/8b4a32f1/attachment.sig>

More information about the Standards mailing list