[Vysper] Some ideas

[Michael Jakl <ja...@gmail.com>]

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).


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.


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". 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.


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.

Cheers,
Michael

Re: [Vysper] Some ideas

[Bernd Fondermann <bf...@brainlounge.de>]

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
>