mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bernd.fonderm...@googlemail.com>
Subject Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Date Mon, 10 May 2010 15:56:38 GMT
On Mon, May 10, 2010 at 17:40, Niklas Gustavsson <niklas@protocol7.com> wrote:
> 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.

ok. we have a draw here. how do we go on?
I don't want to -1 anything, it's simply not worth it.

Is there some solution we could base consensus on?


View raw message