If Atom is going to consider merging with RSS, it should merge with RSS 1.0. I consider it a mistake that this wasn’t done in the first place, primarily as a means to hook into the installed base of RSS 1.0 processors, but also to gain the self-descriptive extensible goodness of RDF.
It seems the Web Service Description WG has opted not to bother trying to fix a glaring architectural flaw in Web services by maintaining the status quo of making it impossible to determine which operation is being requested for any particular (or even a reasonably sized subset of) SOAP messages. Bah.
The issue behind this problem is that the so-called “document exchange” model used by Web services is little more than wishful thinking; If only we hid the operation from the message, then we’d be more loosely coupled, yeah, that’s the ticket!. Sorry folks, it just don’t work like that. What you’ve done by removing the operation is just to make your message less self-descriptive. That’s it. The only gain is saving a few bytes.
If there’s anything worse than RPC, it’s less self-descriptive RPC.
The easiest way that we know to go about “doing away with operations”, is to just give every component the same set of operations. Then you don’t really need to think about them much of the time.
you agree with Chris Ferris? 8-)
(though I still wish he’d stop referring to HTTP as a “transport protocol”)
I subscribed to public-webarch-comments because I like to hear what folks have to say about the AWWW document.
Since Saturday afternoon, the comments list has been absolutely bombarded by spam (to the tune of about 600 messages). It’s like it’s become the Internet’s sweetest honeypot, despite presumably having a handful of subscribers. Spammers work in mysterious ways.
Luckily my new still-being-trained spam filter caught all of them after I trained it on the first one, but still, yikes.
over 900 messages as of late Sunday. Had to unsubscribe to lessen the load on my little P133 gateway box.
Jim Webber joins the fray. Welcome, Jim. Subscribed (sorta – hurry up with the RSS and permalinks! 8-O )
One of his first entries is titled “Messages != Flattened Objects”, which is a topic very near and dear to my heart, and a frequent point of discussion between Jim and myself, both publically and privately.
The term “Flattened Object” is interesting. I hadn’t heard it before, though I do use “serialized” and “pickled” on occasion. This is what I call a “document”; a bag of bits REpresenting the STate of some object.
Yet another WS-* specification with a bunch of Get* methods that fails to use the SOAP 1.2 WebMethod feature which supports HTTP GET and therefore giving important resources URIs.
WS-* effect considered harmful? It appears so.
In my ample spare time, I often fire up one of a handful of multiplayer first-person shooters that I’m familiar with, and play against opponents across the Internet. Perhaps you’ve done this too.
I frequently use a tool called Gamespy3D to help me locate the servers playing the game/mod/map I’m interested in. Of course, sometimes pinging this list of servers takes quite some time, leaving the ever-growing possibility that the ones pinged first are no longer playing the map they said they were N seconds ago. As a result of this, sometimes I double-click on a server, only to end up playing a different map than I intended, wasting up to a minute of my time.
What would be nice is if part of the “join” message that is sent from my PC to the server, contained information which declared “Here is the map I’m interested in playing, and if you’re not playing it right now, I don’t want to join”.
Of course, sometimes you don’t have the expectation that any particular map is being played, such as when you just want to join one where you know your friends hang out. So it should be optional. But when present, its value must be understood.
You know, something like SOAPAction (well, mostly), something that forms languages should support, because that server list inside Gamespy is a form.
Tim notes that Googlebot is frequenting his server, and costing him real money.
A quick investigation on an old page from his log reveals;
HTTP/1.1 200 OK Date: Wed, 03 Mar 2004 14:20:02 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux Last-Modified: Wed, 03 Mar 2004 08:00:54 GMT ETag: "1b404e-f1d-404590b6" Accept-Ranges: bytes Content-Length: 3869 Keep-Alive: timeout=15, max=20 Connection: Keep-Alive Content-Type: text/html; charset=utf-8
Like many other agents and caches, Googlebot presumably uses some “freshness” heuristic based on Last-Modified. As you can see above, Tim’s server is telling the world that even his archived content changes frequently. Ergo, Google hits him frequently. Conclusion; don’t do that! 8-)
Full disclosure; my weblog isn’t cacheable at all – not even any Last-Modified headers – and I have little motivation to fix it because my bandwidth isn’t metered.
ZapThink gets it totally backwards;
Rich clients will supplant portals as the primary interface to Web Services and Service-oriented functionality in the enterprise by the end of 2007.
Bzzt.
These guys need to get out more. Go check out some of the KnowNow or mod_pubsub demos for an example of what’s possible with existing (nevermind next-generation!!) thin-clients.
Sure, a fat-client approach may have some minor advantages (more responsive?), but zero-install is da bomb, baby; once you’ve tried it, there’s no going back. Ask any CIO; they’ll gladly accept a slightly suckier zero-install solution over a fat client solution any day of the week.