JSON-RPC over XMPP
242 views
Skip to first unread message
Matthijs Wensveen
Dec 28, 2008, 5:38:12 PM12/28/08
to jabsorb-user
Hello,
I was thinking about implementing JSON-RPC over XMPP (jabber). I am
looking for a solid JSON-RPC framework in java and extending that and
Jabsorb looks like it's well tested and usable for my purpose.
I am thinking about using the Smack jabber framework to implement the
jabber side of things and for the rest mimicking what JSONRPCServlet
does to implement calling methods and returning values.
Something interesting I am trying to achieve by using jabber, is to
call multiple clients at once when they are in a conference room. Of
course, this will only work when there is no return value.
Are there any pointers you could give me?
Would you be willing to accept my work (when it's done, or at least
usable) as a contribution?
Regards,
Matthijs Wensveen.
I was thinking about implementing JSON-RPC over XMPP (jabber). I am
looking for a solid JSON-RPC framework in java and extending that and
Jabsorb looks like it's well tested and usable for my purpose.
I am thinking about using the Smack jabber framework to implement the
jabber side of things and for the rest mimicking what JSONRPCServlet
does to implement calling methods and returning values.
Something interesting I am trying to achieve by using jabber, is to
call multiple clients at once when they are in a conference room. Of
course, this will only work when there is no return value.
Are there any pointers you could give me?
Would you be willing to accept my work (when it's done, or at least
usable) as a contribution?
Regards,
Matthijs Wensveen.
William Becker
Dec 29, 2008, 4:01:52 AM12/29/08
to jabsor...@googlegroups.com
I was thinking about implementing JSON-RPC over XMPP (jabber). I am
looking for a solid JSON-RPC framework in java and extending that and
Jabsorb looks like it's well tested and usable for my purpose.
Sounds like an interesting project.
I am thinking about using the Smack jabber framework to implement the
jabber side of things and for the rest mimicking what JSONRPCServlet
does to implement calling methods and returning values.
Something interesting I am trying to achieve by using jabber, is to
call multiple clients at once when they are in a conference room. Of
course, this will only work when there is no return value.
Does this relate to comet at all? I have been playing with comet and jabsorb, but have not commited anything to trunk with it yet. If you like I can forward some bits of my code.
Are there any pointers you could give me?
Implementing this, may prove to be similar to the Java Client we have for jabsorb. Check out the org.jabsorb.client package and its unit tests.
Would you be willing to accept my work (when it's done, or at least
usable) as a contribution?
I would have to consult the other devs, but so long as it complements the project, I don't think that this would be a problem. We are quite liberal about giving commit access to people who contribute.
Cheers,
Will
Regards,
Matthijs Wensveen.
Matthijs Wensveen
Dec 29, 2008, 10:47:02 AM12/29/08
to jabsorb-user
Hello,
On Dec 29, 10:01 am, "William Becker" <wbec...@gmail.com> wrote:
> > I was thinking about implementing JSON-RPC over XMPP (jabber). I am
> > looking for a solid JSON-RPC framework in java and extending that and
> > Jabsorb looks like it's well tested and usable for my purpose.
>
> Sounds like an interesting project.
>
>
>
> > I am thinking about using the Smack jabber framework to implement the
> > jabber side of things and for the rest mimicking what JSONRPCServlet
> > does to implement calling methods and returning values.
> > Something interesting I am trying to achieve by using jabber, is to
> > call multiple clients at once when they are in a conference room. Of
> > course, this will only work when there is no return value.
>
> Does this relate to comet at all? I have been playing with comet and
> jabsorb, but have not commited anything to trunk with it yet. If you like I
> can forward some bits of my code.
>
>
Well, yes and no. I don't know a lot about comet, but from what it
looks like it tries to acomplish the same thing. Comet uses server
pushes over http with keep-alive or jetty continuations, polling, or
some other http means. HTML5 has some stuff too.
Instead, I want to abandon HTTP for this kind of communication as it
is not designed (*at all*) for this. Instead, XMPP seems like the
perfect candidate for bi-directional communication, initiated from
either end.
However, I have not yet investigated how to implement a javascript
(XmlHttpRequest) client. As javascript has to use HTTP (or some plugin
which I definitely don't want) this may turn out nasty. I know there
are some javascript xmpp libraries, and I think most of them use
polling to communicate with the xmpp server.
For the moment I'm working on a java-to-java project (simple
multiplayer board game), but I want to create a javascript client as
well. I started out using SOAP, but that involved publishing a
webservice for every client just for some simple game communication
(firewall hell, etc). Of course, low-level socket (TCP) communication
would be possible as well, but is way less interesting (and has the
same firewall issues). This way, maybe some other people can benefit
as well.
>
> > Are there any pointers you could give me?
>
> Implementing this, may prove to be similar to the Java Client we have for
> jabsorb. Check out the org.jabsorb.client package and its unit tests.
>
Thanks, I'll definitely look at that, because I need a java client
anyway.
>
>
> > Would you be willing to accept my work (when it's done, or at least
> > usable) as a contribution?
>
> I would have to consult the other devs, but so long as it complements the
> project, I don't think that this would be a problem. We are quite liberal
> about giving commit access to people who contribute.
I can also supply patches if that's more convenient. But I'm going to
experiment a little first, so don't expect anything really soon.
Matthijs
On Dec 29, 10:01 am, "William Becker" <wbec...@gmail.com> wrote:
> > I was thinking about implementing JSON-RPC over XMPP (jabber). I am
> > looking for a solid JSON-RPC framework in java and extending that and
> > Jabsorb looks like it's well tested and usable for my purpose.
>
> Sounds like an interesting project.
>
>
>
> > I am thinking about using the Smack jabber framework to implement the
> > jabber side of things and for the rest mimicking what JSONRPCServlet
> > does to implement calling methods and returning values.
> > Something interesting I am trying to achieve by using jabber, is to
> > call multiple clients at once when they are in a conference room. Of
> > course, this will only work when there is no return value.
>
> Does this relate to comet at all? I have been playing with comet and
> jabsorb, but have not commited anything to trunk with it yet. If you like I
> can forward some bits of my code.
>
>
looks like it tries to acomplish the same thing. Comet uses server
pushes over http with keep-alive or jetty continuations, polling, or
some other http means. HTML5 has some stuff too.
Instead, I want to abandon HTTP for this kind of communication as it
is not designed (*at all*) for this. Instead, XMPP seems like the
perfect candidate for bi-directional communication, initiated from
either end.
However, I have not yet investigated how to implement a javascript
(XmlHttpRequest) client. As javascript has to use HTTP (or some plugin
which I definitely don't want) this may turn out nasty. I know there
are some javascript xmpp libraries, and I think most of them use
polling to communicate with the xmpp server.
For the moment I'm working on a java-to-java project (simple
multiplayer board game), but I want to create a javascript client as
well. I started out using SOAP, but that involved publishing a
webservice for every client just for some simple game communication
(firewall hell, etc). Of course, low-level socket (TCP) communication
would be possible as well, but is way less interesting (and has the
same firewall issues). This way, maybe some other people can benefit
as well.
>
> > Are there any pointers you could give me?
>
> Implementing this, may prove to be similar to the Java Client we have for
> jabsorb. Check out the org.jabsorb.client package and its unit tests.
>
anyway.
>
>
> > Would you be willing to accept my work (when it's done, or at least
> > usable) as a contribution?
>
> I would have to consult the other devs, but so long as it complements the
> project, I don't think that this would be a problem. We are quite liberal
> about giving commit access to people who contribute.
experiment a little first, so don't expect anything really soon.
Matthijs
Matthijs Wensveen
Jan 19, 2009, 9:31:24 AM1/19/09
to jabsorb-user
Hi,
I thought maybe a status update would be nice...
I have completed implementing the server side in the form of a
JSONRPCXMPPConnection. This object is like JSONRPCServlet, and routes
incoming messages to JSONRPCBridge. It uses a URI that is (tries to
be) compliant with RFC 5122. With this URI you can connect to a jabber
server, and optionally specify a user or chatroom to communicate with,
i.e. "xmpp://user1:pass...@jabber.org", "xmpp://
user1:pass...@jabber.org/us...@jabber.org" or "xmpp://
user1:pass...@jabber.org/ro...@chat.jabber.org?
join;password=roompassword":
------------
JSONRPCBridge.getGlobalBridge().registerObject("test", test);
// connect and publish test object
JSONRPCXMPPConnection connection = new JSONRPCXMPPConnection("xmpp://
test2:test2@localhost:5222");
------------
I have also created a transport / SessionFactory and Session
implementations for the java client. Using it is similar to the java
client for the HTTP transport:
------------
TransportRegistry registry = new TransportRegistry(); // BTW: should
the static TransportRegistry.i() be used??
XMPPSessionFactory.register(registry);
Client client = new Client(registry.createSession("xmpp://
test1:test1@localhost:5222/test2@localhost"));
ITest test = (ITest client.openProxy("test", ITest.class);
test.echo("The mayor of Wezel");
------------
I'm pretty happy about it as it is. I'll send in patches tonight (at
work now).
Next up is a JavaScript client. I suspect this will be a little
harder, as javascript-xmpp is not as easy because the xmpp server has
to support http connections. Some libraries use flash in the
background to overcome this, but I think that that's cheating :) Same
goes for using applets.
I'll try to stick as close to the existing javscript interface, so
using it will only require changing a URI or so.
Cheers,
Matthijs.
PS. When there is time, I'll work on the game that should actually use
the stuff I've made. I'll show it when it's done (don't expect Duke
Nukem Forever... I'll be done sooner :))
I thought maybe a status update would be nice...
I have completed implementing the server side in the form of a
JSONRPCXMPPConnection. This object is like JSONRPCServlet, and routes
incoming messages to JSONRPCBridge. It uses a URI that is (tries to
be) compliant with RFC 5122. With this URI you can connect to a jabber
server, and optionally specify a user or chatroom to communicate with,
i.e. "xmpp://user1:pass...@jabber.org", "xmpp://
user1:pass...@jabber.org/us...@jabber.org" or "xmpp://
user1:pass...@jabber.org/ro...@chat.jabber.org?
join;password=roompassword":
------------
JSONRPCBridge.getGlobalBridge().registerObject("test", test);
// connect and publish test object
JSONRPCXMPPConnection connection = new JSONRPCXMPPConnection("xmpp://
test2:test2@localhost:5222");
------------
I have also created a transport / SessionFactory and Session
implementations for the java client. Using it is similar to the java
client for the HTTP transport:
------------
TransportRegistry registry = new TransportRegistry(); // BTW: should
the static TransportRegistry.i() be used??
XMPPSessionFactory.register(registry);
Client client = new Client(registry.createSession("xmpp://
test1:test1@localhost:5222/test2@localhost"));
ITest test = (ITest client.openProxy("test", ITest.class);
test.echo("The mayor of Wezel");
------------
I'm pretty happy about it as it is. I'll send in patches tonight (at
work now).
Next up is a JavaScript client. I suspect this will be a little
harder, as javascript-xmpp is not as easy because the xmpp server has
to support http connections. Some libraries use flash in the
background to overcome this, but I think that that's cheating :) Same
goes for using applets.
I'll try to stick as close to the existing javscript interface, so
using it will only require changing a URI or so.
Cheers,
Matthijs.
PS. When there is time, I'll work on the game that should actually use
the stuff I've made. I'll show it when it's done (don't expect Duke
Nukem Forever... I'll be done sooner :))
Matthijs Wensveen
Jan 20, 2009, 7:28:35 PM1/20/09
to jabsorb-user
I've been using git-svn to track the jabsorb svn repository while
being able to commit my own changes locally. Does anyone know what is
the best way to create patches for the changes I've made locally.
Currently I use: git diff remotes/git-svn, optionally with a path for
which a diff is to be made. I can mail the output of this command and
I think that can be used as a patch file, but I'm not sure.
being able to commit my own changes locally. Does anyone know what is
the best way to create patches for the changes I've made locally.
Currently I use: git diff remotes/git-svn, optionally with a path for
which a diff is to be made. I can mail the output of this command and
I think that can be used as a patch file, but I'm not sure.
Also, still no JavaScript client. Found some minor bugs in my code and
added some new features, like timeouts etc. Cleaned up de code a
little too.
Regards,
Matthijs
PS. Unfortunately no unit tests. I couldn't come up with a way to
either mock the xmpp connection or use some sort of embedded xmpp
server.
Michael Clark
Jan 21, 2009, 9:25:57 PM1/21/09
to jabsor...@googlegroups.com
Hi Matthijs,
Matthijs Wensveen wrote:
> I've been using git-svn to track the jabsorb svn repository while
> being able to commit my own changes locally. Does anyone know what is
> the best way to create patches for the changes I've made locally.
> Currently I use: git diff remotes/git-svn, optionally with a path for
> which a diff is to be made. I can mail the output of this command and
> I think that can be used as a patch file, but I'm not sure.
>
We have a wiki page on it here:
http://jabsorb.org/SubmittingPatches
> Also, still no JavaScript client. Found some minor bugs in my code and
> added some new features, like timeouts etc. Cleaned up de code a
> little too.
>
> Regards,
>
BTW I'm quite interested in your work. XMPP is a very appropriate
transport protocol for doing async messaging and point to multi-point
messaging and I really hope the browsers will adopt it as a standard
messaging layer for JS web applications. This would be better than
people having to hack and workaround HTTP limitations like comet/bayeux
does. XMPP is a perfect fit for the job.
Regarding using a 1x1 pixel flash app for doing socket comms, I'm
personally not against this (as its use would be optional). I wouldn't
mind to have a general JSON-RPC socket transport client that used this
approach. A Flash/AS3 port of the client for the existing HTTP transport
is something I'm interested in too.
Cheers,
Michael.
Matthijs Wensveen
Jan 28, 2009, 7:12:43 PM1/28/09
to jabsor...@googlegroups.com
Hi.
Trying to find an appropriate javascript lib to connect to a jabber
server turned up a few results (jsjac and xmpp4js seem good
candidates). Unfortunately all of them suffer from 'same origin
policy' restrictions, so it's (almost?) impossible to create a client
that can connect to just any jabber server (without server-side
trickery like a servlet or a proxy). Xmpp4js claims to be able to do
it using something that is removed from the current xmpp specs.
Unfortunately I'm unable to build xmpp4js from source due to some
missing dependency... sigh..
Anyway, the proposition of a hidden flash or applet seems more
appealing now. Not very good in Flash, but definitely in more
widespread use than java (plugin). I'll give it a shot. Hopefully
flash will allow cross-site connections. I think even applets don't
allow this.
It would be good to implement it in such a way that the HTTP transport
could be plugged in as well, and possibly other transport. I very much
liked the way the java client was designed with pluggable transports.
It'll probably take a while though... Any hints or pointers?
Thanks,
Matthijs
PS. I'll read the SubmittingPatches topic asap.
Trying to find an appropriate javascript lib to connect to a jabber
server turned up a few results (jsjac and xmpp4js seem good
candidates). Unfortunately all of them suffer from 'same origin
policy' restrictions, so it's (almost?) impossible to create a client
that can connect to just any jabber server (without server-side
trickery like a servlet or a proxy). Xmpp4js claims to be able to do
it using something that is removed from the current xmpp specs.
Unfortunately I'm unable to build xmpp4js from source due to some
missing dependency... sigh..
Anyway, the proposition of a hidden flash or applet seems more
appealing now. Not very good in Flash, but definitely in more
widespread use than java (plugin). I'll give it a shot. Hopefully
flash will allow cross-site connections. I think even applets don't
allow this.
It would be good to implement it in such a way that the HTTP transport
could be plugged in as well, and possibly other transport. I very much
liked the way the java client was designed with pluggable transports.
It'll probably take a while though... Any hints or pointers?
Thanks,
Matthijs
PS. I'll read the SubmittingPatches topic asap.
Arthur Blake
Jan 28, 2009, 8:58:17 PM1/28/09
to jabsor...@googlegroups.com
Looks like a very interesting piece of work.
On Wed, Jan 28, 2009 at 7:12 PM, Matthijs Wensveen <matthijs...@gmail.com> wrote:
Hi.
Trying to find an appropriate javascript lib to connect to a jabber
server turned up a few results (jsjac and xmpp4js seem good
candidates). Unfortunately all of them suffer from 'same origin
policy' restrictions, so it's (almost?) impossible to create a client
that can connect to just any jabber server (without server-side
trickery like a servlet or a proxy). Xmpp4js claims to be able to do
it using something that is removed from the current xmpp specs.
Unfortunately I'm unable to build xmpp4js from source due to some
missing dependency... sigh..
I'm not too familiar with XMPP but maybe you can hack up one of those javascript libs to get it to work right with cross domain scripting. I would be surprised if flash allowed you to do a cross domain connection (for the same reason you can't do it in a java applet) It's a security risk.
In any event, it is possible to do cross domain Ajax calls, I know of at least one (unrelated) library that has a module for this...
Extjs. Here is the doc page: http://extjs.com/deploy/dev/docs/?class=Ext.data.ScriptTagProxy
Maybe you can apply the same technique to one of the pure JS/XMPP libs (this wouldn't be pure XMPP though would it, rather some form of XMPP over HTTP, right?)
I hope this might help you...
Anyway, the proposition of a hidden flash or applet seems more
appealing now. Not very good in Flash, but definitely in more
widespread use than java (plugin). I'll give it a shot. Hopefully
flash will allow cross-site connections. I think even applets don't
allow this.
Applets definately do not. And I would be very surprised if flash allowed you to (it would be a big security blunder if they did! Think of what a rogue flash applet could do if an unsuspecting user landed on the page- send spam, and generally launch all kinds of attacks across the web on you behalf...)
It would be good to implement it in such a way that the HTTP transport
could be plugged in as well, and possibly other transport. I very much
liked the way the java client was designed with pluggable transports.
It'll probably take a while though... Any hints or pointers?
Thanks,
Matthijs
PS. I'll read the SubmittingPatches topic asap.
I'd like to learn more about XMPP too as I've had a lot of ideas for cool chat related applications.
Keep us updated on your progress!
Good Luck
raziel alvarez
Jan 29, 2009, 10:01:51 AM1/29/09
to jabsor...@googlegroups.com
You can also take a look at the code that GWT produces to perform cross-site requests. Not sure how much of an overkill it would be. Probably ext-js is a better solution.
Matthijs Wensveen
Mar 9, 2009, 10:37:39 AM3/9/09
to jabsorb-user
Hi,
I'm sorry I haven't been actively working on this lately. I switched
jobs recently and have been very busy with that (getting .Net
certified, sigh). Also, my 16-month old son has been keeping me awake
at night, so I try to get every sleep I can get :S. Anyway, I thought
I should inform you of this.
When I have some more time, I'll file a RFE in the issue tracker and
properly attach some patches. As for the javascript client, I think
I'll implement this as an applet, because this allows cross-domain
connections using crossdomain.xml (which is emerging as a de facto
standard, I think). It'll probably be a while though before I can
actively work on this again, unfortunately.
I've been thinking about how we could allow for multiple transport
implementations on the javascript side. Something like what already
exists for the java client would be perfect. Also this should allow
for 'server' objects on the javascript side too (JSONRPCBridge
functionality), when the transport supports 'pushing' data. Let me
know what your thoughts are about this, or if there is any work in
progress that I should take in account.
Regards,
Matthijs
PS. Because I'm working with .Net now, I'll look into JSON-RCP .Net
clients too. Jay!
On 29 jan, 16:01, raziel alvarez <raziel...@gmail.com> wrote:
> You can also take a look at the code that GWT produces to perform cross-site
> requests. Not sure how much of an overkill it would be. Probably ext-js is a
> better solution.
>
I'm sorry I haven't been actively working on this lately. I switched
jobs recently and have been very busy with that (getting .Net
certified, sigh). Also, my 16-month old son has been keeping me awake
at night, so I try to get every sleep I can get :S. Anyway, I thought
I should inform you of this.
When I have some more time, I'll file a RFE in the issue tracker and
properly attach some patches. As for the javascript client, I think
I'll implement this as an applet, because this allows cross-domain
connections using crossdomain.xml (which is emerging as a de facto
standard, I think). It'll probably be a while though before I can
actively work on this again, unfortunately.
I've been thinking about how we could allow for multiple transport
implementations on the javascript side. Something like what already
exists for the java client would be perfect. Also this should allow
for 'server' objects on the javascript side too (JSONRPCBridge
functionality), when the transport supports 'pushing' data. Let me
know what your thoughts are about this, or if there is any work in
progress that I should take in account.
Regards,
Matthijs
PS. Because I'm working with .Net now, I'll look into JSON-RCP .Net
clients too. Jay!
On 29 jan, 16:01, raziel alvarez <raziel...@gmail.com> wrote:
> You can also take a look at the code that GWT produces to perform cross-site
> requests. Not sure how much of an overkill it would be. Probably ext-js is a
> better solution.
>
Matthijs Wensveen
Oct 27, 2009, 7:04:43 PM10/27/09
to jabsorb-user
Hello all,
I've been working a little on this little project again, just to get my hands dirty in java again (only SharePoint and .Net lately).
So far, all the code I've written is separate from the core of jabsorb, that is, there are no modified files, only added ones. I was thinking it might be a good idea to add this as a separate project in the svn repo, so the core can stay clean. It's possible to create a jabsorb-xmpp.jar that works when jabsorb.jar is also on the classpath (in other words, this may be a separate dependency, itself depending on jabsorb).
The XMPP code is pretty stable now. I would like to add some extra exception handling (leaning on the asynchronous java client work I did). It would be fun just to get some XMPP code into some repository.
If you would like for me to create an issue in JIRA, I will do so.
Regards,
Matthijs
I've been working a little on this little project again, just to get my hands dirty in java again (only SharePoint and .Net lately).
So far, all the code I've written is separate from the core of jabsorb, that is, there are no modified files, only added ones. I was thinking it might be a good idea to add this as a separate project in the svn repo, so the core can stay clean. It's possible to create a jabsorb-xmpp.jar that works when jabsorb.jar is also on the classpath (in other words, this may be a separate dependency, itself depending on jabsorb).
The XMPP code is pretty stable now. I would like to add some extra exception handling (leaning on the asynchronous java client work I did). It would be fun just to get some XMPP code into some repository.
If you would like for me to create an issue in JIRA, I will do so.
Regards,
Matthijs
Reply all
Reply to author
Forward
0 new messages