>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 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. Anyway... Is "deadletter" the only possible value for this parameter or can the callback be made by other means as well? 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? Next on to the QOS for update and get.... :) ftp://kalamazoolinux.org/pub/pdf/xmlBlaster.pdf
