Michael Jakl wrote: > Hi! > > I've got some ideas floating around I'd like to discuss with you. > > > XMPP Stanza Inspector. > > Sometimes it would be really good to know what exactly goes over the wire > (excluding the encryption of course). What I'm thinking about is some kind of > pluggable Stanza Inspector that lets us see what stanzas are sent and > inject/modify them as they pass. A metaphor could be a moderator of a > mailing-list. I don't think it's much effort to do, but the usefulness of such > a component is quite limited (debugging).
+1. This would be very useful. This is also part of the bigger plan to have analysis and admistration tools. (I'm not sure of the inject/modify aspect yet, though.) FWIW, I currently tend to use the client's debugging features, Psi, Coccinella and Smack all have them. > Templates. > > Stanzas in Vysper are built using the StanzaBuilder which works similarly to > the StringBuilder. We add elements and attributes onto a stack. What about > using templates instead of a programmatic approach? I think using templates we > could enforce certain restrictions (that is, force attributes directly in the > template if the spec requires them etc.). Additionally I think templates could > be pluggable too. For example an publish action includes an item element, so > does a notification and a response for the request for all items. Using > templates such nestings *could* be done easier (and less error prone) than > with StanzaBuilder. Of course good abstractions/generalisations with > StanzaBuilder work well too, yet I think templates are even easier to > maintain. +1. This is a pretty good idea. Having a template stanza and only set the values which differ. (But keep in mind: Responses/Forwards sometimes/often are required to also retain non-standard inner elements which might can not be foreseen when defining the template.) > Validating Streams. > > The XMPP specifications and XEP extension specifications include XML Schema > definitions which could be used to validate a stanza-stream on the fly (which > is one big XML "file", essentially). If we configure our XML parser to be > validating with these schema files, we'd have a very rigorous error detection > in terms of "correct Stanza syntax". We currently use our own 'XML parser' (it's more a 'XMPP XML parser'). It has no notion of an XML schema currently and for sure cannot easily be 'configured' to validate. Instead you'd have to extend it into a full blown XML parser, or better: replace it by one. When I looked at XML parsers I found them unable to 're-parse' partial XML and they had a big overhead (validation is part of the overhead ;-)). Rigorous error detection in terms of correct XMPP-XML syntax is already there (maybe incomplete or buggy, but it's there) because the standard requires that. This is also true for the basic syntax and semantics of IQ/presence/message (see ProtocolWorker.processStanza()). When it comes to XEP-specific semantics, well, I'd rather be liberal in what to accept. > To check whether a request is semantically > invalid is still up to our code, but catching the easy ones early seems to be > a > good thing to me. Dealing with malicious and misbehaving clients starts here, > I > think. Not sure that I agree. Where I totally agree is that there should be upper bounds for stanza lengths, XML element nesting levels etc. Please note, that in XEP-0004, section 10 'XML Schema' starts with the words: "This schema is descriptive, not normative." So the relevance of XML schemas might be limited. > There is no immediate need to do any of this right now (if there ever will be > one), but discussing it and hearing more input would be nice. Yeah, great post Michael! Thanks, Bernd > > Cheers, > Michael >
