X-log

X-log : Let the data flow!

John Robb
Scripting News
Andre Durand
Six Apart
ActiveRenderer
Tech Central Station
Seblogging
My ZT1180
Storage
Our First Baby

X-log

Tuesday, April 2, 2002

Drivel: This is only the beginning.

Andersen Faces Breakup as KPMG Talks Fail. In another big blow to Andersen, plans to merge the accounting firm's non-U.S. operations with KPMG were called off today. By Reuters. [New York Times: Business] 10:35:19 PM comments ()

Drivel: Grid computing is going to be an interesting phenomenon. The concept of Grid computing has been around for about five years. It evolved out of the high-performance and scientific computing interest groups in academia and the government. As I have been doing research and analyzing various software packages, it is interesting to see the intersection between what has evolved on the Internet (and what has come to be known as web services) and high-performance computing. There is a ton of overlap, but the overlap occurs at different levels with different points of focus. The energy of the collision of web services and Grid computing is going to produce products that will drive computing for the next one hundred years. 10:33:37 PM

comments ()

Drivel: I woke this morning and found a nice diagram of implementing Jabber for RCS and Radio post by DJ Adams. This is nice. It is exactly what I envisioned in my previous post with the exception of using XML-RPC or SOAP between the RCS and the Jabber server. You could use Jabber instead of XML-RPC with the work that has already been done in Jabber.root. 10:59:31 AM

comments ()

Drivel: I found an interesting thread on the Jabber site this morning while I was doing follow up research from last night. XML-RPC support in Jabber. It is about a year old and I can't much of anything else about it on the site, but this is enough to get the Radio community going. 10:50:00 AM

comments ()

Drivel: I think I have figured out what my problem is with respect to getting traction with my blog -- I am not open enough. I don't readily share what is on my mind. I like to sit back and ponder things for a while before posting. A perfect example -- this post. I have been thinking about this post for days. I have a lot of interesting things going on that I think a lot of people would be interested in. I just posted my current projects under "Current Projects" in my instant outline. These projects have been going on for months, but I just didn't share them. I am currently researching Grid computing and working on a contract to benchmark vendor reference architectures (e.g. IBM's Websphere, BEA Weblogic, etc.) from a network and systems performance stand point. In addition, I am contributing to the Radio and Globus communities. Now that I have this out, it is really cool. I couldn't be working on anything cooler than the things I am doing right now. Life ain't so bad. Now I just need to figure out how to get paid for all this stuff. 1:35:24 AM

comments ()

Drivel: There has been a lot of discussion today about integrating Jabber into Radio. A lot of confusion has transpired from these discussions. To help provide some context around the discussions of publish-subscribe systems, as they are being discussed, I have compiled some links to academic and Jabber specific resources.

Model-Checking Publish-Subscribe Systems: This a good overview of generic pub-sub systems.
Security Issues and Requirements for Internet-Scale Publish-Subscribe Systems: This is a good overview of scaling Internet based pub-sub systems.
JEP 21: Jabber Event Notification Service (ENS): Event notification is closely tied to pub-sub.
JEP 24: Publish/subscribe: Pub-sub in Jabber.
Jabber Protocol Draft: The core Jabber protocol.

The Connection to IM section in Dave's Publish-Subscribe Walkthrough is great up to item number four where it says that the IM server is notified of a change, via SOAP or XML-RPC. The IM server only knows how to speak its IM protocol, in this case Jabber. The server that detects a change would send a message to the IM server telling the server to broadcast the change to subscribers. The message to the subscribers would be a Jabber.RPC call to the appropriate Radio function on the workstation as Jeremy Bowers has outlined in his work on Jabber.root. This approach raises some interesting issues with Jabber being able to handle thousands, potentially millions, of subscribers to a single resource. For that matter, how many resources can a single Jabber ID have associated with it? What we are talking about here is creating a Jabber resource for every OPML and RSS file on a Radio Community Server. There would even be Jabber resources created for files not on the RCS but that Radio users on that RCS subscribe to (e.g. CNET's RSS feed or feeds from News Is Free). I wonder if the Jabber guys have any thoughts on this?

The most aesthetically pleasing way to implement Jabber on the UserLand platform would be to create a Jabber client and server in the Radio Community Server and a Jabber client in Radio. Jeremy has already started work on the Radio client. The foundation is in Jabber.root to do all of this. It would be cool to see Jabber be a pref that I can select to handle notifications, subscriptions, and upstreaming.

12:56:15 AM

comments ()

Last update: 7/1/03; 7:37:55 AM.