Adam Williams wrote: >>>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? > Good idea, i have never thought about this. Currently 'unrelated' is any available callback server (with or without a login of the client which established the callback server). 'Available' means that the address passed can connect to the callback server.
> >. . > > > >>>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. > Is done (on the current development branch). > > > >>>Next on to the QOS for update and get.... :) >>> >>> >>The connect QoS is big as well :-) >> >> > >Yes it is. > > > regards, Marcel
