>>Ok, I think I've re-tooled to take care of the above problems, but I >>haven't attacked the Key DTD as I want to get the QoS stuff straight >>first. >>I've added a slide for the <queue> tag in subscribing, but the example >>leaves alot of questions. Why is it "relating='unrelated'"? The >This is reserved for future to allow unrelated subscribes. The subscribe >is in this case not related to a login session with its specific callback >channel. You can subscribe and and pass a callback address with the >subscribe (currently this is only possible on login). An example is a >client which subscribes for a dumb toaster or vacuum cleaner which are >not capable or intelligent enough (or have no login account) to do it >themselve.
So is unrelated the only value or could one also specify the logon of the session? . . >>exact relationship to having selected onOverFlow="deadletter" and >>"callback type='EMAIL'" or is the dead letter not really a "letter" but >>simply a message that can be conveyed via any support callback method? >Exactly, the deadletter has nothing to do with email, it is just a >special named message >containing a lost message. >Probably we should rename the feature to 'deadmessage'? That would be nice. >>Next on to the QOS for update and get.... :) >The connect QoS is big as well :-) Yes it is. -- ---------------------------------------------------------------- This message undoubtedly processed by the purely benevolent "US Department of Homeland Security", but don't worry... they're only goal is to protect life, liberty and the pursuit of property.
