eXtensible Application Transport Protocol (XATP)
on
HTTP's Days Numbered
·
· Score: 5, Interesting
HTTP does have it's problems, and it's one of the reasons that Jabber has it's own internal transport protocol to accomplish IM.
I've seen other proposals for HTTP replacements and have been less-than-pleased by their complexity and design. Based on what I've learned from Jabber, and great feedback from many in the open source and standards communities, XATP was born:
XATP, the eXtensible Application Transport Protocol is very simplistic and geared to operate at a layer below content, identity, framing, and other application-level issues. Check it out and offer feedback or participate if your interested.
This story links to jabber.com (which is fine) but if you're looking for the open source project you might want to hit jabber.org. The open source project is where it all started, and jabber.com is just one of the many commercial efforts working to help jabber be a better tool for the business world and enterprises.
We're still a young project and have many hurdles to leap yet, so if you bump into anything you'd like to see improved with jabber, it's open source and we welcome any/all assistance:)
We're working hard on integrating Jabber into Mozilla as a native client. Since Jabber is based on XML and Mozilla's own XML functionality is quite advanced, it should be an interesting combination:)
Unfortunately, it's proven quite challenging to integrate two rapidly developing platforms, so if anyone would like to help and can eat XUL/JS for breakfast, let me know.
With Jabber and Mozilla, you'll instantly have AIM, ICQ, Yahoo, MSN, and others as we progress. Of course, there's no way in hell it will ship w/ the offical Netscape, but it will be part of Mozilla.
There is already an open-source effort to create a free instant messaging protocol: Jabber.
It's made a significant amount of progress and has a tremendous amount of support behind it, and works with AIM/ICQ/talk/IRC/etc transparently. Check it out and help get it done if you are interested:)
I've spoken with the Project Manager for MSN Messenger, and have a good understanding of where Microsoft is heading and what their plans are for future extensions. Also, I have a current copy of the protocol they are using, RVP, based mostly on the HTTP-DAV standard.
Being heavily involved in the Instant Messaging arena via Jabber, I can understand Microsoft's need to deploy this functionality and keep it as open as possible, since the fight is against the entrenched closed systems.
So far I have seen nothing that leads me to believe that they are doing anything sly here, it appears that they honestly want to deploy an open messaging platform, using their own protocol until a standard one is available. An upgraded client should be out this fall along with a server component that works with Exchange, but anyone is free to develop an independent server and/or client that interoperates, and that is exactly what I'll be working on adding into Jabber.
I can't guarantee Microsoft will stand behind their plans or keep it as open as they are saying, but I know that if they didn't it would cause a bigger press headache than AOL is experiencing over this, so I doubt that will happen. I think it's safe to say that for once we can look at Microsoft as a partner in this battle against closed instant messaging platforms.
Hey all... Jabber is still moving along and just about ready to break into the big-leage.
I've been insanely busy with normal life this past month, but at the same time preparing to take Jabber to the next level. Look for a few announcements and a big boom in development over the next month or two.
On a side note, I have successfully already used any Jabber client to communicate to ICQ and AIM users transparently, the code will be cleaned up and available soon.
Anyone even remotely involved in the Mozilla project knows that what is claimed above is completly untrue.
Everyone is quick to dismiss Mozilla as a failure because of the lack of outside involvement and time it's taken, but that is so so untrue. The reasons for this are simple and have nothing to do with the viability of the project, in fact, they prove how viable of a project it is!
Mozilla has taken so long because less than a year ago they basically decided to throw everything away and START OVER, yes, that's right, start pretty much from scratch. This means completly redesigning the entire architecture and reimplimenting it according to those new designs. The fact that they have a usable browser that is quickly approaching completion in less than a year is nearly HEROIC!
The reason for the dearth of outside involvement is fairly simple to explain... it's complex, it's a rapidly moving target, and everyone who can help others jump in are too busy to do so. Very very few people could just download the source for this beast and be able to start hacking it, and even if they could, it's likely to change in a week or two.
Mozilla is an amazing and incredibly successful project. The tools available at mozilla.org and the modularity of the design are simply generations above and beyond any other open project ever attempted. In time everyone will start to see this, go check it out now and start getting involved now before the wave!
IMHO there isn't supposed to be a conclusive "so XXXX is true" point of this article, but instead it's meant to be an expression of view, a description of a vision of ourselves.
And for that, I really enjoyed it... it's always going to be benificial to do a 180 and take a look at yourself and how your consciousness percieves the world, and then relate any new insights there back to the world in which you operate(which is computers/net for many of us).
It was refreshing and dead-on target for many of us. Maybe the problem is that many of those who don't agree aren't able to abstract themselves from reality? But if you're one of those you can't tell, as this article hints at.
I know it's commercial, but it's built on the same technologies(for the most part).
I once administrated windows95.com on a P90 with 32MB of ram running Apache 0.8.X, using BSDI, and it ran like a champ topping our T1 out at around 2 million hits/day(peaked at 4M/day frequently).
There was quite a bit of kernel and apache tweaking involved, but it makes a statement for these technologies.
It does determine who is online, providing instant status updates.
And as far as protocols, it doesn't need to show what they are using(although it can), because anything you send to them via Jabber will be translated on the fly to whatever protocol they are using if they are not Jabber users themselves.
Yes, everything else is superfluous, that is why Jabber is what it is, exactly what you state(plus the superfluous stuff too:)
Yes, I'm planning on server file transfers through the server, probably using HTTP(specifically the WebDAV extensions) and letting Jabber communicate the locations/passwords for the files.
The files don't even need to be stored on the server, it can be a socket-to-socket copy in a server process, but storing them might be a usefull option, especially for broken downloads and group sends.
I agree 1000% and this is exactly why I did Jabber. It may also be just another IM client/server system, but it is more. It was _designed_ to be interoperable with all other instant messaging systems from the start, so if you are using a Jabber client, you can talk to anyone else on any other system, and they can talk to you.
Within a short period of time(months), I expect Jabber to reach the "near-universal" interoperability.
I'll be honest, I'm not a big IRC user, although I admire the architecture.
I was thinking, though, that a Jabber transport could be used to create seamless communication with IRC users, and vice versa. The Jabber users wouldn't really live in a room or be able to participate in the rooms(use a real IRC client for that) but could send IRC users messages like "user id@EFnet" and the Jabber IRC transport would do the translation.
The Jabber server is ready, if someone familiar with the IRC protocol wants to code this:)
1) The links in the Users section going to the overview was an accident, although the overview is really the only data there and yes, way overqualified for most users. It will be "nicer" after a public stable release.
2) File transfer or anything dealing with big binary chunks isn't going to be part of the main protocol. My current plan is to impliment all of those activities through HTTP/1.1 and WebDAV which is perfectly suited for that application, and just send the startup/location information through Jabber.
3) Not sure totally what you mean... thinking...
4) Because tools for manipulating/processing XML are quickly becoming standard and available. Secondly, XML is just a wonderful way to wrap up data, and it's text, easy to deal with in any situation.
5) Mirabilis uses UDP because ICQ is central-server based, and there is no way that their servers could possibly support a few million TCP connections. Jabber has no central server, so doesn't have that restriction, although very busy Jabber servers will have to deal with some problems because of TCP also, but there are ways of fixing it.
I also use talk, finger, etc... and you can count on Jabber working 100% WITH those utilities(if the Jabber server administrator installs translators for those services), and also have alias Jabber functions like jtalk, jwrite, jfinger that work identically but go directly to the jabber server instead of through a translator.
I live on the CLI, but many/most of my friends do not, and I want to be able to talk to them... hence Jabber:)
I've put great thought into these also, and the Privacy part is going to be addressed via different built in "privacy" levels in the server. One of them will be absolutely invisible, the only way someone would know you existed is if you sent them a message, and then they could only reply...
The security I'm leaving for version 2, but I'm making sure not to do anything to get in the way of it. Using something like PGP could already be used in the existing architecture, but would have to be supported by the client.
Slashdot Mirror
HTTP does have it's problems, and it's one of the reasons that Jabber has it's own internal transport protocol to accomplish IM.
I've seen other proposals for HTTP replacements and have been less-than-pleased by their complexity and design. Based on what I've learned from Jabber, and great feedback from many in the open source and standards communities, XATP was born:
http://xatp.org/
XATP, the eXtensible Application Transport Protocol is very simplistic and geared to operate at a layer below content, identity, framing, and other application-level issues. Check it out and offer feedback or participate if your interested.
Jer
This story links to jabber.com (which is fine) but if you're looking for the open source project you might want to hit jabber.org. The open source project is where it all started, and jabber.com is just one of the many commercial efforts working to help jabber be a better tool for the business world and enterprises.
We're still a young project and have many hurdles to leap yet, so if you bump into anything you'd like to see improved with jabber, it's open source and we welcome any/all assistance :)
We're working hard on integrating Jabber into Mozilla as a native client. Since Jabber is based on XML and Mozilla's own XML functionality is quite advanced, it should be an interesting combination :)
Unfortunately, it's proven quite challenging to integrate two rapidly developing platforms, so if anyone would like to help and can eat XUL/JS for breakfast, let me know.
With Jabber and Mozilla, you'll instantly have AIM, ICQ, Yahoo, MSN, and others as we progress. Of course, there's no way in hell it will ship w/ the offical Netscape, but it will be part of Mozilla.
Yeah, the jabber.org site isn't feeling too healthy at the moment. That's actually on schedule for fixing today :)
We've been pouring 100% of our concentration into the code the last month, and most of the core developers are on irc.openprojects.net in #jabber.
'pologize for the site probs!
Jer
This is exactly what Jabber is all about, building a whole new IM architecture that is also transparently compatible with existing products.
The Jabber project is exactly that. Check it out, there is some work to be done yet so jump in and help out if you're interested!
Check out Jabber, a clean architecture designed to do just that and
support simple/clean/fast clients, and has made significant progress already.
It's an open-source project so it could use any/all help and suggestions!
There is already an open-source effort to create a free instant messaging protocol: Jabber.
:)
It's made a significant amount of progress and has a tremendous amount of support behind it, and works with AIM/ICQ/talk/IRC/etc transparently. Check it out and help get it done if you are interested
I've spoken with the Project Manager for MSN Messenger, and have a good understanding of where Microsoft is heading and what their plans are for future extensions. Also, I have a current copy of the protocol they are using, RVP, based mostly on the HTTP-DAV standard.
Being heavily involved in the Instant Messaging arena via Jabber, I can understand Microsoft's need to deploy this functionality and keep it as open as possible, since the fight is against the entrenched closed systems.
So far I have seen nothing that leads me to believe that they are doing anything sly here, it appears that they honestly want to deploy an open messaging platform, using their own protocol until a standard one is available. An upgraded client should be out this fall along with a server component that works with Exchange, but anyone is free to develop an independent server and/or client that interoperates, and that is exactly what I'll be working on adding into Jabber.
I can't guarantee Microsoft will stand behind their plans or keep it as open as they are saying, but I know that if they didn't it would cause a bigger press headache than AOL is experiencing over this, so I doubt that will happen. I think it's safe to say that for once we can look at Microsoft as a partner in this battle against closed instant messaging platforms.
Jer
jeremie@jabber.org
Hey all... Jabber is still moving along and just about ready to break into the big-leage.
I've been insanely busy with normal life this past month, but at the same time preparing to take Jabber to the next level. Look for a few announcements and a big boom in development over the next month or two.
On a side note, I have successfully already used any Jabber client to communicate to ICQ and AIM users transparently, the code will be cleaned up and available soon.
Watch jabber.org or join the developer's list and stay tuned!
Beware, the story above is MAJOR FUD!
Anyone even remotely involved in the Mozilla project knows that what is claimed above is completly untrue.
Everyone is quick to dismiss Mozilla as a failure because of the lack of outside involvement and time it's taken, but that is so so untrue. The reasons for this are simple and have nothing to do with the viability of the project, in fact, they prove how viable of a project it is!
Mozilla has taken so long because less than a year ago they basically decided to throw everything away and START OVER, yes, that's right, start pretty much from scratch. This means completly redesigning the entire architecture and reimplimenting it according to those new designs. The fact that they have a usable browser that is quickly approaching completion in less than a year is nearly HEROIC!
The reason for the dearth of outside involvement is fairly simple to explain... it's complex, it's a rapidly moving target, and everyone who can help others jump in are too busy to do so. Very very few people could just download the source for this beast and be able to start hacking it, and even if they could, it's likely to change in a week or two.
Mozilla is an amazing and incredibly successful project. The tools available at mozilla.org and the modularity of the design are simply generations above and beyond any other open project ever attempted. In time everyone will start to see this, go check it out now and start getting involved now before the wave!
IMHO there isn't supposed to be a conclusive "so XXXX is true" point of this article, but instead it's meant to be an expression of view, a description of a vision of ourselves.
And for that, I really enjoyed it... it's always going to be benificial to do a 180 and take a look at yourself and how your consciousness percieves the world, and then relate any new insights there back to the world in which you operate(which is computers/net for many of us).
It was refreshing and dead-on target for many of us. Maybe the problem is that many of those who don't agree aren't able to abstract themselves from reality? But if you're one of those you can't tell, as this article hints at.
Jer
I know it's commercial, but it's built on the same technologies(for the most part).
I once administrated windows95.com on a P90 with 32MB of ram running Apache 0.8.X, using BSDI, and it ran like a champ topping our T1 out at around 2 million hits/day(peaked at 4M/day frequently).
There was quite a bit of kernel and apache tweaking involved, but it makes a statement for these technologies.
It does determine who is online, providing instant status updates.
:)
And as far as protocols, it doesn't need to show what they are using(although it can), because anything you send to them via Jabber will be translated on the fly to whatever protocol they are using if they are not Jabber users themselves.
Yes, everything else is superfluous, that is why Jabber is what it is, exactly what you state(plus the superfluous stuff too
Jer
Yes, I'm planning on server file transfers through the server, probably using HTTP(specifically the WebDAV extensions) and letting Jabber communicate the locations/passwords for the files.
The files don't even need to be stored on the server, it can be a socket-to-socket copy in a server process, but storing them might be a usefull option, especially for broken downloads and group sends.
Jabber is under the GPL at this point, but if need be, I'm willing to put it under another license to make it compatable.
Besides, Mozilla would only need a client, and clients are quite easy to write.
Jer
I agree 1000% and this is exactly why I did Jabber. It may also be just another IM client/server system, but it is more. It was _designed_ to be interoperable with all other instant messaging systems from the start, so if you are using a Jabber client, you can talk to anyone else on any other system, and they can talk to you.
Within a short period of time(months), I expect Jabber to reach the "near-universal" interoperability.
See my reply above to "why not IRC?", I think Jabber and IRC can work together very nicely :)
I'll be honest, I'm not a big IRC user, although I admire the architecture.
:)
I was thinking, though, that a Jabber transport could be used to create seamless communication with IRC users, and vice versa. The Jabber users wouldn't really live in a room or be able to participate in the rooms(use a real IRC client for that) but could send IRC users messages like "user id@EFnet" and the Jabber IRC transport would do the translation.
The Jabber server is ready, if someone familiar with the IRC protocol wants to code this
1) The links in the Users section going to the overview was an accident, although the overview is really the only data there and yes, way overqualified for most users. It will be "nicer" after a public stable release.
:) Will fix!
2) File transfer or anything dealing with big binary chunks isn't going to be part of the main protocol. My current plan is to impliment all of those activities through HTTP/1.1 and WebDAV which is perfectly suited for that application, and just send the startup/location information through Jabber.
3) Not sure totally what you mean... thinking...
4) Because tools for manipulating/processing XML are quickly becoming standard and available. Secondly, XML is just a wonderful way to wrap up data, and it's text, easy to deal with in any situation.
5) Mirabilis uses UDP because ICQ is central-server based, and there is no way that their servers could possibly support a few million TCP connections. Jabber has no central server, so doesn't have that restriction, although very busy Jabber servers will have to deal with some problems because of TCP also, but there are ways of fixing it.
6) Sorry about the speling
Thanks!
Jer
I also use talk, finger, etc... and you can count on Jabber working 100% WITH those utilities(if the Jabber server administrator installs translators for those services), and also have alias Jabber functions like jtalk, jwrite, jfinger that work identically but go directly to the jabber server instead of through a translator.
:)
I live on the CLI, but many/most of my friends do not, and I want to be able to talk to them... hence Jabber
There will definately also be a command to do this for Jabber, soon probably.
jwrite user@server.com "message"
or
echo "message" | jwrite user@server.com
Jer
I've put great thought into these also, and the Privacy part is going to be addressed via different built in "privacy" levels in the server. One of them will be absolutely invisible, the only way someone would know you existed is if you sent them a message, and then they could only reply...
The security I'm leaving for version 2, but I'm making sure not to do anything to get in the way of it. Using something like PGP could already be used in the existing architecture, but would have to be supported by the client.
Jer