Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XML abstraction #65

Open
sonnyp opened this issue Mar 7, 2013 · 4 comments
Open

XML abstraction #65

sonnyp opened this issue Mar 7, 2013 · 4 comments

Comments

@sonnyp
Copy link
Contributor

sonnyp commented Mar 7, 2013

I open this issue as a discussion around XML abstraction, please tell me if you think it's not the right place.

I believe NXB is mainly used for web application. Unfortunately with the depreciation of E4X there is no future for XML parsing on the Web except for DOM based parsing which is inefficient for XMPP and isn't available in Web workers.

http://wiki.xmpp.org/web/BoshIssues#JSON_Content_Type
http://xmpp.org/extensions/inbox/json.html
I believe JSON could be a viable alternative as it is probably the fastest parsable format for the Web.
An alternative could be to provide a higher JSON based API abstraction that isn't a simple XML<->JSON mapping.

@dhruvbird
Copy link
Collaborator

@sonnyp I think this is totally relevant and would love to see a standard emerge around this since I know different providers (talk.to, imo.in, etc...) are trying their own custom implementations and that doesn't help anyone.

JSON is definitely a good option since it is supported by many languages and browsers natively, and would probably be better for the battery life of hand-held devices.

A consistent mapping from XML to JSON would provide an easy transition path for many implementations, and that is definitely positive. Providing a higher JSON based API abstraction could be left for later since it seems like a longer term investment, and depends on the need for it esp. considering emerging technologies.

I'm more than happy to discuss my (limited) experiences with this if that can be of any help!

@sonnyp
Copy link
Contributor Author

sonnyp commented Apr 27, 2013

Related: https://github.com/lloydwatkin/xmpp-ftw and https://github.com/legastero/stanza.io

For xmpp-ftw the parsing XML<->JSON is done server side while it's done client side for stanza.io

Correction: XMPP-FTW provides a protocol abstraction server side

@sonnyp
Copy link
Contributor Author

sonnyp commented Oct 2, 2013

A consistent mapping from XML to JSON would provide an easy transition path for many implementations, and that is definitely positive. Providing a higher JSON based API abstraction could be left for later since it seems like a longer term investment, and depends on the need for it esp. considering emerging technologies.

True, and I'm actually starting thinking it wouldn't make any sense (for node-xmpp-bosh) to go further simple XML<->JSON mapping as node-xmpp-bosh only provides standards XMPP transports.

Also it seems XMPP-FTW has already went pretty far on transport/protocol abstraction.

@dhruvbird
Copy link
Collaborator

it wouldn't make any sense (for node-xmpp-bosh) to go further simple XML<->JSON mapping as node-xmpp-bosh only provides standards XMPP transports.

For sure. It would make sense to have a JSON view and ingestion plugin.
With xmpp-ftw, does bosh become a redundancy? I mean it would be great if it could take over that functionality. esp. since it runs on socket.io. I don't know how pervasive bosh is these days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants