[Council] VOTE: JEP-0079 (Advanced Message Processing)
rob at cataclysm.cx
Thu May 20 21:31:28 CDT 2004
OK, I've finally completed a review of AMP. In general, I don't see
anything that is inherently unimplementable from a server perspective.
But, I do agree with some of the issues raised on the wiki.
> Regarding Detail 1 ("Some error reporting text and examples should be
> added..."): I'll add some examples to each condition and action. As
> for processing, my initial thought was (as described in section 2.2:
> "Server Processing") the server would validate all of the rules it was
> given before trying to process them. If this seems too expensive, then
> we can see what would work better, although I think fully validating
> before processing would be more reliable.
Perhaps just mention what should be done if an invalid rule is
encountered, and not talk about the algorithm. It could probably be
optimised if the rules are validated as they're evaluated, and if an
invalid rule is encountered, the whole thing dies. That would make
processing of an invalid ruleset slower (especially if the invalid rule
is further down), but valid rulesets faster (only one pass required).
> Regarding Detail 2 ("If the <message/> is dispatched to another
> server..."): The intent is that servers MUST NOT forward AMP-ed
> messages to another server unless the recipient at understands AMP.
> Requiring (not simply allowing) disco lookups every time is
> unrealistic. However, I believe it is also unrealistic for an
> AMP-supporting server to make assumptions that are too broad. Would it
> be more acceptable to say something like the following?
> Before forwarding a <message/> with AMP semantics to another server,
> it MUST be aware of the receiving server's support for this
> This very well could mean that a server will need to perform a disco
> request before it can forward the first AMP-ed <message/> to a
> particular server it has no prior knowledge of.
That change makes sense (though in reality, I would've ignored the
requirement to disco every time - as long as it looks like the rules are
being followed from the outside, thats enough for me).
> [Somewhat OT: Maybe we need some form of "expiry flags" for disco info
> and items? Better than assuming any cached disco info is valid
A good idea for an extension JEP.
> Regarding Detail 4 ("The expire-at condition will have a strange
> interaction with..."): Yes, implementations are expected to garbage
> collect expired messages, unless you have better ideas. If it doesn't,
> then how can the system be reliable?
> The expense of this depends on your implementation. One possible
> implementation is to have a database of exiprable messages, which should
> be significantly smaller than the entire message store. This task would
> scan this database periodically (but frequently), and perform the
> necessary actions for those messages that have expired, and flag it as
> discardible. Then the next time an attempt would be made to deliver the
> message (e.g. the user is now available), a scan of that same database
> could be made, and it would actually be removed then.
The traditional implementation of expiry in offline messages just
discards the messages before they are delivered when the user comes
online. At least for j2, having to scan would be painful, due to the way
the data is stored (though most activities where polling is required
doesn't scale well).
I'm not sure yet if implementing JEP-0013 (Flexible Offline Message
Retrieval) is going to require a change of the way expired messages are
handled. If it does, then the above will probably be moot.
> Regarding Detail 6 ("6.3.3 is impossible over multiple hops."): The
> point of expire-in is a TTL. Maybe the term used should have been
> "live-for" or some such. Other TTL implementations I have seen did not
> require synchronized clocks, provided the clocks ran at the same rate
> (which I think is safe to assume here). It can be safely assumed (and
> should be explicitly stated) the "base timestamp" for a particular hop
> is the moment the message is received. Since the value MUST be adjusted
> (decremented by the processing time), the "base timestamp" is adjusted
> for each hop.
I'm not sure that "expire-in" can reasonably be used, since its highly
dependent on the server architecture and the distance the message is
Example: in j2, if you send a message to someone on the same server, the
c2s -> router -> sm -> router -> sm
(Yes, looks odd, but there is a reason for the loop).
Each of those arrows is a seperate TCP connection. So, the time to
complete processing on that packet is going to be much longer (and more
complex) than in a simple server where the entire server is contained in
a single process with no logical seperation between c2s/router/sm (ie
simple IM-only servers, which do exist).
Additionally, it requires more complexity in the implementation - In the
above, I'd either need to detect this rule in every piece of the server
(which I really don't want to do, it breaks the abstraction), or be
inaccurate, since only the the second sm instance would pick it up, and
by then its too late.
Is there a use case for "expire-in"?
> Regarding Detail 8 ("In 6.3.4, if the value is 'other',..."): This is
> correct. I had some (possibly irrational) problem having a condition
> with only one option to it. Maybe "other" should just go away...
I think it should. The double-negative ("would not deliver to a
non-resource JID") threw me for a while, and it doesn't add much anyway.
One other comment, with regard to the question on the wiki, "Do we
really want grossly unreliable notifications/alerts?"
I think these alerts might still be useful. They're only as unreliable
as every other message we send around the place.
I assume that if a server receives a message that has a "status" on the
<amp/> chunk, then it should do no AMP processing at all but simply
recognise that this is some kind of reply, correct? Otherwise, the
potential for crazy loops exist - one server sends a notify, and another
server sends a notify in response, and so on.
And lastly, I suppose that "notify" and "alert" are basically the same
thing, they're just providing two different "levels" of notification.
[Slightly OT: if we had a protocol for specifying the "importance" of a
stanza's content (not used for processing, just an indicator for the
client), then we could have a single "notify" action and couple it with
this. But we don't :) ]
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://jabber.org/pipermail/council/attachments/20040521/c5fd17a6/attachment.pgp
More information about the Council