I've always thought Bosworth a good thinker and this post about 'What is the platform?' helps frame the re-alignment of the information and software industries towards immediately useful globally scalable services rather than piece-meal products that are basically construction kits.
Although this has been said before by many people, seeing a key individual shift from Microsoft to BEA to Google and see their thought shift as well is a strong indicator of the future. I just wish he mentioned that Amazon sells blenders, bicycles and boots in addition to books and movies... (and you can sell your used stuff there, and there are auctions too...)
September 29, 2004
E4X getting some press
Jon Udell has a good intro piece to ECMAScript for XML from AgileDelta. A great combination of scripting and XML for fluid and barrier free programming - some good people there at AgileDelta.
September 24, 2004
Why I still hate HTTP
PixelCort has some good points in Why I still hate HTTP.
I have nothing against Jabber. I like the DNS domain name integration. I just think that HTTP could also be used.
- HTTP has been around since before 1990. It’s showing its age.
TCP/IP has been around even longer. Yikes. - Backwards compatability can be a good thing, to a point. But eventually you have to move on or start over.
I'm not attempting some sort of backward compatibility. Just pointing out that a new-fangled problem like notifications isn't really all that new or fangled and didn't require a new solution - notifications are a form of transferring state and work well with REST based systems and HTTP. - HTTP was designed for hypertext.
Yet is serves images, audio, stylesheets, xml and much more just fine. Odd that. - It’s all about the messaging. If HTTP can do all this, why are we using SMTP also?
Good question. You should ask HotMail, Yahoo Mail, and GMail the same question. - HTTP is an abstract way of messaging, through a different manner.
Not really. It's a way of transferring the state of resources.
- It’s client-server-server-client: me@pixelcort.com sends message to pixelcort.com, which sends message to yoursite.example.com, which sends message to you@yoursite.example.com. Yes, there are two middlemen, but it’s worth it. I maintain a constant connection to pixelcort.com from my client, you maintain a constant connection to yoursite.example.com from your client, and the two servers will maintain keep-alive connections as needed by messages being passed between them.
This is also how mod-pubsub works. - Messages are XML. Create a schema, use a namespace, and you’re all set.
Yes, XML is cool. Sending other content types is also useful. - You don’t know until you try.
True. True. That's why I tried doing real-time notifications with HTTP. You should look into it.
I have nothing against Jabber. I like the DNS domain name integration. I just think that HTTP could also be used.
Hammered by another hurricane
A great friend of mine is in Florida and about to be hammered by another hurricane:
Well, lookee here...here comes Hurricane...Jeanne! Dead nuts on for Palm Bay which is about 20 miles due south of our home. Still early to gauge where landfall will be, and intensity is still relatively low. Current wind speed projection for landfall is 109 mph. Most people mainland are staying (not much choice), while all beachside just received the mandatory evacuation notice. I'll be boarding up tonight..just took them down Wednesday. Some forecasters have indicated to expect higher tornado incidents due to the storm's configuration. Due to sudden change of direction, yesterday, and expected landfall on Sunday, the only real evac options are slim...west side of FL will get pounded, too. Not enough gas in the region still, most stations here are closed now...a full tank (if you have one) will get you to Georgia or Alabama assuming you can find a place to stay. Alabama just got hit last week, so they're out of supplies, fuel, and vacancies as well. Leaving Georgia, which will likely get hit by Jeanne as well. Flights from Orlando and Jacksonville are booked. News is reporting no vacancies in Southern FL, largely due to all the people staying to help rebuild infrastructure from the last three hits.
...so, we gonna' hunker down and ride it out. The walls are concrete block filled with poured concrete, windows are impact rated to 113mph (we cover anyway to prevent risk of losing roof), the garage doors are reinforced with steel, all roof beams and crosses are tied down through the concrete block all the way to the foundation. The wind outside will sound scary, but we should be okay. The real danger comes from tornados setting down...a window of risk beginning as early as 12 hours before hurricane makes landfall. I'll send updates out periodically, as long as we can until we lose power.
Got plenty of water and supplies, and we'll be singing a lot of kumbaya. :)
- A.
September 21, 2004
Bosworth peering into the soap bubble
Hmmm, Adam Bosworth's gaining clue.
Adam Bosworth's most excellent blog has a mighty interesting snippet
I'm not sure if I should jump in with my obligatory flurry of links to mod-pubsub and other 'notifications over the Web' technologies, since I'm pretty sure he knows about them.
Adam Bosworth's most excellent blog has a mighty interesting snippet
I'm trying, right now to figure out if there is any real justification for the WS-* standards and even SOAP in the face of the complexity when XML over HTTP works so well. Reliable messaging would be such a justification, but it isn't there. Eventing might be such a justification, but it isn't there either and both specs are tied up in others in a sort of spec spaghetti. So, I'm kind of a skeptic of the value apart from the toolkits. They do deliver some value, (get a WSDL, instant code to talk to service), but what I'm really thinking about is whether there can't be a much simpler kindler way to do this.
I'm not sure if I should jump in with my obligatory flurry of links to mod-pubsub and other 'notifications over the Web' technologies, since I'm pretty sure he knows about them.
Are Web Services receding?
I think it's too early to give up on Web Services, but there definitely is a lot of frustration in the industry surrounding the complexification of numerous unimplemented WS-standards.
What Simon says in Are Web Services receding? bears watching:
What Simon says in Are Web Services receding? bears watching:
That makes me wonder if Web Services are on their way to a CORBA-like market: sort of interoperable, vendor-ridden, and critically important to a small number of people. If that's the case, then maybe the rest of us can return to vanilla XML HTTP, sometimes known as REST.
September 18, 2004
Why is it they hate HTTP?
PixelCort has to say this Why I hate HTTP:
This sounds like a simple interview question at Amazon - "so, how would you make it work anyway?". Okay folks, let's break some assumptions: Not every client has to connect to the One True Server. There is this concept of an 'intermediary'. You can use this to place a thousand caching servers that retrieve the data, then clients retrieve from those servers instead. One level of indirection gives you n*2 more scalability. Two levels give you how much? Anyone? Anyone?
And this:
Well, duh. Of course. And this is a unique problem because... what? The solution is simple and applies to any protocol - put a server on the desktop & send it a message. And for your next complaint in this sequence, here's a question for you - how is your pet protocol going to post messages to a desktop without the client opening a socket (like an http server) or initiating a connection (like an http client) of some kind?
See http://www.mod-pubsub.org/ for an example of a client that initiates a connection and then consumes a stream of event notifications on that connection. There are clients in multiple languages (Java, Perl, Python, C++) and even two servers (Perl, Python). The neat thing is, it's just HTTP, so all the documents & design has been done. You just have to follow in someone else's footsteps.
Even if a million people check using all of these bandwidth savers, that’s still a million TCP connections being opened and closed. That’s just not going to scale well as we get larger and larger audiences.
This sounds like a simple interview question at Amazon - "so, how would you make it work anyway?". Okay folks, let's break some assumptions: Not every client has to connect to the One True Server. There is this concept of an 'intermediary'. You can use this to place a thousand caching servers that retrieve the data, then clients retrieve from those servers instead. One level of indirection gives you n*2 more scalability. Two levels give you how much? Anyone? Anyone?
And this:
HTTP servers can only speak when spoken to. They can’t just connect to the client, the client has to initiate the connection. Even with keep-alive, they still have to wait until an HTTP method is incurred. By not being able to have that two-way communication, how can we truly maintain HTTP as our protocol of choice?
Well, duh. Of course. And this is a unique problem because... what? The solution is simple and applies to any protocol - put a server on the desktop & send it a message. And for your next complaint in this sequence, here's a question for you - how is your pet protocol going to post messages to a desktop without the client opening a socket (like an http server) or initiating a connection (like an http client) of some kind?
See http://www.mod-pubsub.org/ for an example of a client that initiates a connection and then consumes a stream of event notifications on that connection. There are clients in multiple languages (Java, Perl, Python, C++) and even two servers (Perl, Python). The neat thing is, it's just HTTP, so all the documents & design has been done. You just have to follow in someone else's footsteps.
September 17, 2004
XML.com - Fallacy and Lunacy
Chuckle for the day from XML Deviant Fallacy and Lunacy:
SOAP specs have little specs upon their backs to spite 'em
And little specs have lesser specs, and so ad infinitum.
September 12, 2004
WWW cubed - syndication and scale
Bill sure writes well in WWW cubed: syndication and scale:
Hey... these guys are good...
The most advanced thinking that doesn't involve throwing out the Web is probably Rohit Khare's PhD thesis [pdf], which suggests an 'eventing', or push style extension to the Web model. An early example of this approach where the server calls back to the connected client instead of the client initiating each time, called mod_pubsub is available as open source. One of HTTP's designers, Roy Fielding, is rumoured to be working on a new protocol, that could feature support for easing of the load on servers.
"The question of responsibility – especially in the event of operational issues arising – becomes complex. With a pull delivery model on the other hand, organisational boundaries are crisp and clear." This may not matter for consumer applications, but a surprising number of important business systems and services are now based on HTTP data transfers. And many people believe that syndication technology like RSS and Atom will also be used for commercially consequential exchanges in the b2b, or "business to business" arena. Switching from a polling to a pushing mode, also confers a switching of responsibilities, and this might in time have far-reaching consequences where cost-efficiency is traded for risks, legal and financial. One day, your online bank might be morally and technically culpable for getting your bank statements to your computer. In that case, expect to sign even more of your rights away in the fine print.
Hey... these guys are good...
September 11, 2004
blog notifications and content distribution
More coolness and convergence happening. Ironic that today is a day where a distributed network of commited individuals try to improve the world. This is all about NOW - Notifications On the Web.
decentralized web(site|log) update notifications and content distribution / September 9, 2004 8:25pm @ trainedmonkey:
This is pretty much what mod-pubsub (and many others) can do right now via HTTP. There is a SourceForge project that has clients in several languages (I did one of the Java clients - there's a Snoop console app that's fun to use to peer into the stream) and two server implementations (one in Perl and one in Python).
decentralized web(site|log) update notifications and content distribution / September 9, 2004 8:25pm @ trainedmonkey:
maybe it's useful to sketch out a scenario of how i envision this working: i decide to track a site like boing boing, so i subscribe to it using my aggregation client. when it subscribes, it gets a public key (probably something i fetch from their server, perhaps embedded in the rss/atom feed). my client then hooks into the notification-and-content-distribution-network-in-the-sky, and says "hey, give me updates about boingboing". later, the fine folks at boing boing (or xeni) post something, and because they're using fancy new software that supports this mythical decentralized distribution system, it pushes the entry into the cloud. the update circulates through the cloud, reaching me in a nice ln(n) sort of way. my client then checks that the signature actually matches the public key i got earlier, and goes ahead and displays the content to me, fresh from the oven.
This is pretty much what mod-pubsub (and many others) can do right now via HTTP. There is a SourceForge project that has clients in several languages (I did one of the Java clients - there's a Snoop console app that's fun to use to peer into the stream) and two server implementations (one in Perl and one in Python).
Polling gets more attention
More goodness from Bob Wyman regarding blogs and pubsub :
If you must poll, at least poll well...:
He also suggests using RFC3229 - Delta encoding in HTTP but I'm not sure that specification is required or advisable. This discussion is a good starting point to figure out if there are any lingering problems with RFC3229.
I think that 'telling the server' could be done purely with a URI and does not require the use of headers. There would be a trade-off in terms of coordination between the use of headers (for example, as defined by RFC3229) and the use of URIs (separate resources for sets of items based on time).
If you must poll, at least poll well...:
[...] we can do better by having clients tell the server when they last picked up new data and then having the server only send entries that have been added or modificed since the last entry picked up by the client.
He also suggests using RFC3229 - Delta encoding in HTTP but I'm not sure that specification is required or advisable. This discussion is a good starting point to figure out if there are any lingering problems with RFC3229.
I think that 'telling the server' could be done purely with a URI and does not require the use of headers. There would be a trade-off in terms of coordination between the use of headers (for example, as defined by RFC3229) and the use of URIs (separate resources for sets of items based on time).
September 10, 2004
Perfect Search
Interesting view on the future of Web-scale search. Perfect Search
Before we can have our intelligent-assistant DWIM mind-reading turing-complete search engine, we'll have something ghastly like SQL on top of a semantically-tagged representation of the web. 20 minutes of manual searching and reading will be turned into a few seconds of work. Hal can be built on top of those APIs, but skilled humans will use them first. It will be way cool to search with.
Arthur C. Clarke and Search Alerts
Holy cow - Bob Wyman discovers that Arthur C. Clarke invented search alerts! I'm sure I read that book when I was young - I wonder if it's been in the back of my mind ever since...
Vogels "Once More: Polling does not Scale."
Vogels is right on with Once More: Polling does not Scale. However... it sure is easy to implement, and 'controlled polling' will help get things to move up one order of magnitude. What about controlled polling with a chain of caching services providing multi-layer fan-out? How far could that go? Or is that equivalent to using a 'neighbor'?
September 05, 2004
Jobs - Amazon metadata service
Great job with Amazon - designing bigger and better metadata systems for all product data at Amazon:
We will be working through data management problems that are at the heart of Amazon.com and all content-rich web systems. This is your chance to be a part of a team that will enable the next generation of web systems. If your background includes such things as knowledge representation, semantic networks, derived ontologies, formal concept analysis, or conceptual structures, and you have a strong software development base, then you'll be a perfect fit for this team.
September 04, 2004
T-Mobile blocks TxTMOB messages
Via Boing Boing :
Did T-Mobile block TxTMOB messages during Convention?
No new updates on the validity or cause, but didn't someone once say that freedom of press is limited to those who own one?
Did T-Mobile block TxTMOB messages during Convention?
Highlighted text below, from the txtmob dispatch: "T-Mobile blocked TXTmob messages during a portion of the RNC. "
My only question is, WTF? Since when does T-Mobile decide which messages are ok, and which aren't? What, in my contract with them, specifies that they can decide which messages I am allowed to get? Who told who to block which messages? I'm no lawyer, but those seem like the kinds of questions that lawyers are interested in.
No new updates on the validity or cause, but didn't someone once say that freedom of press is limited to those who own one?
Batch operations for network requests
Savas touches on a point that I've slowly been pondering - the relationship between batch operations and a REST approach (interestingly this is in context of managing pubsub subscriptions):
Batch operations for network requests are a critical element of performance which enhances scalability - at least within a single organization. A REST based approach with explicit support would be fairly easy to outline, but I'm thinking it might be easier to model this as pipelined requests. Not sure. If anybody has any thoughts, drop me a line.
If WS-Addressing message information headers are used in this way in specifications, we can't define a message which can carry multiple subscription IDs; in the case, for example, one wanted to cancel multiple subscriptions with one message:
Batch operations for network requests are a critical element of performance which enhances scalability - at least within a single organization. A REST based approach with explicit support would be fairly easy to outline, but I'm thinking it might be easier to model this as pipelined requests. Not sure. If anybody has any thoughts, drop me a line.
Diffusion of 'service oriented' meme
Jeff has a nice sample point on the diffusion of 'service oriented' within the industry (from Service Oriented Enterprise).
There are several good points, this is just a sample:
He also mentions ramping up at one new employee every 5 days - that's amazing. I only wish that were true of my particular group at Amazon...
There are several good points, this is just a sample:
desire to have pure SOAP as well as a slimmed down XML services (no RM, Sec or TR)
He also mentions ramping up at one new employee every 5 days - that's amazing. I only wish that were true of my particular group at Amazon...
Subscribe to:
Posts (Atom)