-
“Traffic Web Services are also available through the Traffic REST API.” Erm, so there’s an RSS API *and* a REST API? Does .. not .. compute. REST != XML/HTTP. I’d say scrap the “REST API”. Nice work otherwise though. Keep it coming.
-
“Ashwin walked us through the SOA Architectural Big rules. I made notes, crossing out the errors and replacing them with the relevant REST principles.” A good read.
-
Heh, he said “MIME Typen”. I hope I’m not offending anyone by finding that cute 8-)
-
Heh, I love it; SOA as Beta 8-) P.S. Jeff, the VHS version came out 15 years ago, not 5. 5 years ago somebody tried to put video on 8-track 8-)
-
“Can the Web fulfill industry and business requirements?” Pretty much, yah.
-
“Also, there is no logout button. I plan to take care of both problems for new schemes in Mozilla.” God bless you, Rob Sayre.
Just a quick followup on a previous piece, Ajaxian picked up a couple of declarative Javascript stories today;
- Declaritive Ajax components and XML namespaces, referencing a great Dave Johnson post.
- a new ZK Google Maps components, which is used declaratively
Any move of the pendulum in this direction is a-ok by me. But to be clear, I am glad it’s a pendulum … meaning that there’ll always be a place for script (the bleeding edge), but we need to consolidate common practice periodically. This also gives us the opportunity to support the functionality natively in the browser.
How has Mobile Web 2.0 come to this;
One way that Web 2.0 companies can similarly adjust their services for mobile devices is by relying less on browser-based applications and more on small software clients that users can download onto their phones. “The browser will fade into the background,” said Wood.
The article’s not all bad though (in fairness, the main message is obvious – as Micah says, “Duh”). It also warns against “naive copying of PC services” (which I assume he means Web sites primarily targetted at PC users – a subtle but important distinction), which is good advice, but here’s a tip for mobile folks; if you find yourself moving outside the browser, or doing so while not using Web technologies (widgets), you’re not doing Web 2.0. It might be “Mobile 2.0”, but it’s not Web 2.0, and therefore not “Mobile Web 2.0”.
And this…
He used the example of Google Maps, an application initially designed for the PC. Because the application is built on Ajax, like many other Web 2.0 services, it pushes data out to the client device in order to speed up future user requests. On a mobile phone, that process drains battery life, eats up limited memory and results in potentially very high data-access charges. Google Inc. has introduced a version of the program designed for mobile phones that eliminates some of that overhead, improving the mobile user experience.
Well, guess what; using the phone drains the battery, consumes memory, and costs money. Mapping on a phone is going to use more resources than, say, doing email, which in turn will use more than checking the current time. But so what? Mapping is resource-intensive (although you could certainly do better than Google has).
Have you ever used the fat-client Google Maps Mobile referred to above? It’s not exactly the posterchild for efficient use of resources – I’ve got (well, RIM had 8-) the phone bill to prove it. I’m not saying the Web version doesn’t consume more, but I would be surprised if a little optimization couldn’t bring it in line with the midlet. Besides, I’d bet that if you asked Google the reasons they created it, resource consumption would be way down the list, and the lack of widely deployed AJAX stack on mobile devices would be at the top … which is rapidly changing, of course.
While the unique needs of mobility should always be acknowledged, and normally accomodated, remember that there lies a very slippery slope … the same one that WAP happily slid down years ago by internalizing the belief that mobile was so special that it needed non-interoperable mobile equivalents of every protocol from IP on up. And while there are, as always, exceptions – apps that are much better off as an installable app than a Web app – are you certain that yours is one, and do you realize what you’re sacrificing by going that route?
-
Not just the usual “Cool URI” suggestions…
-
Why REST kicks SOA ass in one word.
-
Doh, it should have been on the Web all along!
-
Hmm, I like the idea of a common substrate for Python Web apps, like Servlets provides for Java. But a *gateway* interface for doing it? Ack. IMO, that layer needs to reflect HTTP to the upper layers properly, as Servlets do.
-
A funny name for an application protocol which tramples over HTTP by confusing it with a session layer protocol. Doh.
-
RFC 2616 + errata + reference updates
-
Thanks, Paul.
-
“The question is, do they really get it?” I’d love to be wrong, but I suspect not.
-
It scares me to think that the dweeb I knew at Nortel’s Computing Technology Labs – whose claim to fame at the time was an “agent system built atop HTTP” – could have been a billionaire.
-
Ay carumba. How hard is it to just say “WS-Transfer is a piece of crap”? I doubt anybody would be offended anymore since, AFAIK, nobody’s implementing it.
-
So if “2.0” is the new big thing, and it takes Microsoft three versions to get it right, well , erm …. 8-)
-
Coach fails the “404; bug or feature?” test.
-
“If you ignore the S in SOA for a moment and shine an uncompromising light on your organization’s software development practices, you may come to realize that there perhaps are some simple fundamentals you need to work on first, so that you can then appro
-
“The trend of talking about things without defining them and then revelling in the fact that they are ill-defined really makes me wonder for the future of discourse in the software industry”. Amen!
-
This guy wins my “Best user name” award of the day; omarshariffdontlikeit. Presumably inspired by http://www.urbanaddiction.com/archives/000881.html
-
The LA Times takes up the cause … 8-)