[Standards-JIG] NEW: Message Archiving

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Tue Jun 8 08:22:29 UTC 2004

On Sunday 06 June 2004 8:17 pm, David Yitzchak Cohen wrote:
> servers, for instance.)  In either case, it's useful to know both when
> the message was sent and when it was received (just like SMTP).

But that is server-to-server, not server-to-client.  I don't see a "download 
date" of any of my mail I've received over POP3 or IMAP, and it isn't really 
important information anyway, at least in the context of mail.

Just to throw another idea out here...  What if the server were to do the 
logging automatically?  I'd like to make this possible within the protocol.  
A "download date" would definitely be meaningless in this scenario.

> Here's my take: since the JID isn't a unique key for finding a collection
> anyway, you might as well toss the whole idea of a collection "having"
> a JID.  When you ask the server for a list of collections with a certain
> JID, it can simply search for collections having messages to/from that
> JID.  (In practice, the server can maintain a list of JIDs "involved" in
> any given collection (or possibly a list of collections in which a given
> JID is involved - which is faster will probably depend on the density)
> in order to avoid a performance hit in the lookups.)  Another neat
> advantage here is that in MUC, you can archive entire groupchats, and
> you'll be able to find conversations where XYZ participated easily.

Hmmm.  I think this makes it more complicated to generate a listing, as then 
you have to search the entire collection to even determine who is involved, 
and this might end up being many addresses.  What if you want to make an 
application that lists all of the collections in a box with 2 columns: "JID", 
"Description" ?  The first column wouldn't even make sense unless you could 
guarantee that there is only one other participant, or they all came from the 
same muc room.  Maybe we need a 'type' attribute in the collection, to 
indicate two-party vs muc.

> You might as well just have both required, but allow the server to supply
> defaults for any that aren't supplied:
> client supplies________|server assumes______________
> to=a,from=b____________|to=a,from=b_________________
> to=a___________________|to=a,from=you_______________
> from=a_________________|to=you,from=a_______________
> _______________________|to=you,from=you_____________
> This kinda simplifies all the rules from a client perspective, and makes
> conformance testing easier for the server.


> > A related issue is how to deal with JID resources.  Logging both the full
> > to/from JIDs in the message stanza would allow us to retain this
> > information, however it is also completely redundant, since the resources
> > should never change in a normal conversation.
> Picture a situation where I'm chatting with you from /work, and then
> I get off in the middle in order to get on /mobile, where I continue
> chatting with you, and finally, arriving at /home, we finish up our
> conversation there.  (Never say never, eh?)

I'm aware of this, but I didn't think the various chats should be part of the 
same collection.  Currently, the above scenario would result in 3 separate 
chat interfaces (you with obviously 3 clients, and me with 3 different chat 
windows under one client), and 3 different <thread> values.  Granted, not all 
clients would necessarily have to operate this way, but the compliant ones 
do, and you can see how this would logically imply 3 separate collections.

> Let's not make two different protocols, one for MUC and one for standard
> messages. . .

Fine, but we should at least have a "type" attribute that would provide some 
 1) if type=muc, all jids have the same bare jid
 2) if type=chat, there are only two jids in the whole collection

And for type=chat, I continue to stress that these should be full jids.  A new 
resource means a new collection.

> > Notice that there would then be no distinction between 'a' and 'b' in a
> > groupchat.  The person doing the actual logging is no different from any
> > other participant, aside from that his jid would be the 'a' in the
> > collection (maybe this could be an optional field then).
> interesting ;-)

Another positive point of the a/b thing is that you could easily alter the 
file "to protect the innocent" by just changing the collection header, 
although I don't know how compelling this is.


More information about the Standards mailing list