On Mon, May 10, 2010 at 17:40, Niklas Gustavsson <[email protected]> wrote: > On Mon, May 10, 2010 at 4:10 PM, Bernd Fondermann <[email protected]> > 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? Bernd
