mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: [Vysper] Some ideas
Date Sat, 04 Jul 2009 21:20:58 GMT
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
> 


Mime
View raw message