[JDEV] Message timestamps.

[Thomas Charron]

Quoting Scott Robinson <quad at jabber.org>:
> > the message packet by the end transport, by simply copying the tags of
> the
> > stream into the tags of the message.
> Hee. I've been thinking about that as well and left it out of the document
> for a very specific reason. We can't specify any sort of XML standard into
> the etherx server/streams protocol. (though a lot of it is very iffy right
> now) I only specified for the Jabber-XML protocol because that's all we
> really could pin down.

  Understandable, but the LEAST we can do is make the rout tag less transport
specific, aka, the transport tag itself..  My example simply named it a
timestamp tag.  Timestamping of TAGS is usually attribute based, but this is
ongoing stamps of something pretty close to a transaction, which I would say is
not really an attribute.  I'd like to see a tag OTHER then 'transport' used, and
I'd settle for the timestamps being attributes to that tag.

> > <route>
> > <timestamp type='sent'>
> > <id>Id of marker</id>
> > 19991009T0635
> > </timestamp>
> > </route>
> >=20
> I only had sent and received in there because they are the base minimum.
> "stored", "attemptedsend", "archived" are just the beginning of further
> tags
> I had mind. ;) (though I named them differently)
> The great thing about XML is that because I specified only sent and
> received, it doesn't force us to them. I just believed that in all
> situations, they would be a base minimum.

  I can agree with that.

> In the situations of "stored", "attemptedsend", and "archived", I believe
> it
> would be better to add an "type" tag (similar to what you have above) and
> use the "sent" and "recevied" attributes for timestamping.

  Alrighty, we're getting somewhere..  I can work with that logic..  But that
would mean that we should document the attributes that we're going to use so
there is NO confusion, and have them very firm, else, it won't work..  The ONLY
reason why I would like to see a type tag was for clients that can handle the
route tag, but not really ALL of the attributes as we add them.  Simular to how
we are looking at the message tag..  Aka, message type='error'.  A simple client
just says 'Oh, message'.  They could them do the same thing..  'Oh, timestamp,
I'll add it to the list', and not needing to know beforehand what KIND of
timestamp it is..

> I know this could be improved upon. Ideas?

  See above for my reasoning.  I think each 'stamp' should be a seperate and
distinct entities.  This would allow for us to expand the use of the route tags
without a client needing to know each possible attribute, as I said above.  This
would mean that clients could simply display the 'type' attribute of each
timestamp, and have correct information.  IMHO, easier to parse this way as
well.  Each 'signing' of the message, Aka, routing, is seperate and distinct.

> >   Of course, the use of tags versus attributes is up to opinion, and I

> According to XML recommended usage, the timestamp should be an attribute.
> ;)

  Timestamping of a transaction based tag.  But we're timestamping an entire
'transaction'.

  Perhaps something along the lines of:

<route>
<stamp type='recieved' time='991010T0630'>
Sometransport.jabber.org with whatever text
</stamp>
<stamp type='sent' time'991010T0630'>
someother transport
</stamp>
</route>

> Do I smell a flame war coming?

  Ok..  KDE RULEZ!!  Oh wait..  GNOME RULES!!  No, I know, Linux ROCKZ!! 
NoNoNo..  Linux SUKZ!!

  ;-P

--- 
Thomas Charron
<< Wanted: One decent sig >>
<< Preferably litle used  >>
<< and stored in garage.  ?>>