Adam Williams wrote: >>o Page 3 >> This is the qos of a publish() in Pub/Sub mode >>o Page 4 >> This is the qos of a publish() in PtX mode >> (The XPath is not implemented yet) >>o Page 7 >> <content>false and <meta>false is not implemented, but >> we should a soon the first user complains :-) >> It is simple to add but takes time for testsuite etc. .. >>Interesting is the QoS of the update() messages, they contain >>a lot of information. >> >> > >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.
>maxMsg, maxSize, and onOverFlow parameters make sense. But the term >"deadletter" seems confusing, as to those of us with a back ground in >mail servers a dead letter is a letter composed but never sent. > Ok, probably you are right. We have stolen the term from MQSeries (from IBM) which use it to sent unrecoverable messages as dead letters. Specialized clients (e.g. an administrator or a recorder) subscribes for dead letters to handle them 'manually'. >Anyway... Is "deadletter" the only possible value for this parameter or >can the callback be made by other means as well? > /** message queue onOverflow handling, blocking until queue takes messages again */ public final static String ONOVERFLOW_BLOCK = "block"; /** message queue onOverflow handling, send a message marked as dead letter */ public final static String ONOVERFLOW_DEADLETTER = "deadLetter"; /** message queue onOverflow handling, erase the message silently */ public final static String ONOVERFLOW_DISCARD = "discard"; /** message queue onOverflow handling, take the oldest message from queue and erase it and stuff in the newest */ public final static String ONOVERFLOW_DISCARDOLDEST = "discardOldest"; /** message queue onOverflow handling, throw an exception */ public final static String ONOVERFLOW_EXCEPTION = "exception"; This are possible solution if a queue overflows. For callback currently only deadLetter is implemented (block as well, but this makes no sense since the server may dead lock). On client side for the msg-recorder block, discard, discardOldest, exception is implemented. Currently all this is under redesign - a persistent queue will allow similar behaviour on client side (especially for cluster nodes) and for callbacks. The behaviour will probably be a plugin, allowing users to code other behaviour if they wish. We have scheduled this until 12/2002. > If so what is the >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'? > >Next on to the QOS for update and get.... :) > The connect QoS is big as well :-) > >ftp://kalamazoolinux.org/pub/pdf/xmlBlaster.pdf > > > > > > > thanks and keep on your valuable work (it is a good feedback as well) Marcel
