[Council] JEP - 0023
mass at akuma.org
Mon May 13 12:02:02 CDT 2002
DJ Adams wrote:
<snipped comments and code>
>So, what mod_offline.c does here is calculate based on pure seconds, rather
>than a physical timestamp. I'm assuming this was intentional for the very
>reason you state. A 'secret' attr 'stored' is used to work out the number of
>seconds the message was in storage (/me thinks of Eddy Murphy's dusty porsche
>in "48 Hours" for some reason) and subtracted from the 'public' attr 'seconds'
>when it gets finally forwarded.
>So the argument about a time-based TTL across non-synchronized servers is
>perhaps not appropriate, as the T is expressed in neutral seconds. This is
>of course assuming (now, as before) that the time taken between storage events
>is negligible (otherwise a cross-server TTL would be virtually impossible to
I think my comments stand; the expiry information is only processed for
offline messages within the existing implementation, meaning that a
twenty second delivery path will not cause messages with a one second
delivery expiry to be tossed; they will be delivered unless they are
sent to offline. Even without this, time would need to be synchronized
between machines in order to have accurate TTL; the best you could do is
change the original seconds stamp before rebroadcast, but that is not an
ideal solution (besides changing the message, you will be ignoring
network transmission time).
Its easier to just say what this really does; it allows offline messages
to time out, or to not be delivered if the recipient is unavailable. It
does not affect delivery to available delivery endpoints in current
implementations, and really cannot without imposing some manner of time
synchronization between components and between server across the internet.
>Secondly, I wonder how useful a per-hop TTL (as you suggest) would be. It's
>the originator that usually sets the TTL for obvious reasons, and one can
>hardly expect either the intermediate stations to (re)impose a further TTL
>(if that makes sense) or the originator to know the number of hops, or more
>relevantly the number of offline storage events, a message might take
>(especially for example in the light of the new component-related offline
>storage feature in 1.4.2).
I don't think a per-hop TTL would be very useful at all - one across all
hops including the recipient client might be (if they look at this
meeting request within five minutes, it doesn't make sense for them to
ever get it). Even then - in the realm of IM, you would probably end up
wanting to have the message for UI reasons.
More information about the Council