mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Gustavsson <nik...@protocol7.com>
Subject Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Date Mon, 10 May 2010 15:40:00 GMT
On Mon, May 10, 2010 at 4:10 PM, Bernd Fondermann <bf_jak@brainlounge.de> wrote:
> Well, if <item> has the same semantic in all cases, this would be perfect.
> If it carries different semantics for both #user and #admin, you'd have
> different signatures for the method anyway, to propagate these semantics.

Sorry, I probably did not make my example as clear as I've could have.
The example only serves to illustrate how we would have to backtrack
in what context an element is created, that it might not show
immediately where I create an element what type (the namespace URI is
as important as the local name in the identity of an element) the
element is.

> So basically, you're proposing to design an API which requires saying:
> * I want to use ns 'http:123' on element 'iq'
> * I still want to use ns 'http:123' on inner element 'query'
> * I still want to use ns 'http:123' on inner element 'items'
> * Yes, I still want to use ns 'http:123' on inner element 'item', really!

Yes, that's correct.

> which is redundant.

An explicit. I would think this comes down to a matter of taste, which
of course differs.

> And you justify this by emphasizing that everybody
> else does which is ok from an XML parser PoV, but not so much from a
> Vysper PoV.

I'm not sure where I see the Vysper XML API would need to differ from
any other XML API, as the perform the exact same task.

> Why? Because the impact of implementing this would be:
> * Changing a lot of working code, potentially introducing bugs, without
> adding any information which isn't already there.

I believe this is now complete, but like you say, there might have
been regressions introduced as in any significant change. In this
change, from my point of view (or perhaps matter of taste), we added
lots of information of what elements we're actually creating. I no
longer have to extrapolate this from the context (something my
admittedly limited brainpower tends to find hard).

> * Making stanza creation much more verbose, cluttering namespaces all
> over the place.

Cluttering for you, making it clear for me.

> * Tracking everywhere if a stream is c2s or s2s, to appropriately be
> able to add xmlns='jabber:client' vs. xmlns='jabber:server'

Right, again, this makes it clear in what case an element must be used.

> I don't want to go through all this.
>
> If the renderer/writer is intelligent enough to derive the ns, then
> please let's follow "DRY", regardless of other APIs.

To me, this is not a case of having clever code (which we do and did).
It's a matter of having clear and (while I don't really like this
term) self-documenting code.

> XMPP doesn't need a full blown XML parser.

Right, nor do we have one. We currently support the exact XMPP subset
with one configurable addition, comments. Personally I don't intent to
write a fully compliant XML API, the DTD stuff in particular does not
seem very useful for me in the streaming case, but since the current
API is reusable in other contexts, others might have different views
on this.

> So I can see basically two
> options:
> 1. Introduce (aka. keep) ways to make the renderer intelligent enough
> (well, effectively make the API intelligent enough).
> 2. Rollback Vysper to it's own, buggy-but-sufficient XML handling code.

The current API is my best effort of producing an XML API which I find
straight-forward and attempting to follow the principle of least
astonishment. And that I think will be most familiar for other
developers. But, this is merely judged from my limited point of view,
and taste will differ.

/niklas

Mime
View raw message