feedLike many others, I have learned to classify MS Office as bloat-ware, and I avoided using Office 2004 on the Mac. But Office 2008 for Mac changed all that. PowerPoint 2008 on the Mac is simply the best for making presentations. In particular, the list metaphor used for the so-called SmartArt Graphics makes creating consistent-looking diagrams a breeze, with a clear separation of content and presentation. It is a great idea.
Sanjiva says
Oh yeah we support both WS-* and RESTful services. However, they won't meet the RESTafarian fanatics like Tim Bray's coolaid drunkenness level of REST .. but if you want to do pragmatic work with services and support either or both of WS-* and REST then take a look at Apache Axis2 (Java & C), WSO2 WSAS, WSO2 Mashup Server, WSO2 WSF/{C,C++,PHP,Perl} etc...
Is supporting a uniform interface (REST) and a non-uniform interface (WS-*) at the same time in a given server possible without violating some or all the constraints of REST? Or, is this approach, which was expressed by several others (sorry - don't have references handy), based on the POX interpretation of REST (i.e. transport some XML over HTTP treating HTTP as though it is just wire-level protocol)?
I have another exciting milestone to announce for Cyclogz. After several hours of marathon coding over the last few days, I added automatic geotagging support for Flickr photos. Now, I can see my ride photos with the rest of the ride data, conveniently on a map. With this update, geotagging is a simple process of letting Cyclogz know the rider's Flickr ID. Cyclogz will search the rider's photos, geotag them automatically, and generate a slide show. At this time, I am not saving the geotagging data back to Flickr, but I will get to that soon.
Here is an example
Apparently there is a JSON-RPC working group and a proposal to marshal RPC over HTTP. The description is quite simple:
Sergey Beryozkin is wondering about
is it what actually defines Web Services ? Not only the actual technology per se but the fact that multiple businesses can do the same technology and successfully interoperate?
Will it ever happen with RESTful services ? Will it be possible for multiple companies to interoperate with more sophisticated things involved such as transactions, for ex, something which is possible to do with WS-BusinessActivity which does not really lock all involved ?
...
Or is it something which will not be ever needed in practice ?
What is striking about the WS-Empire striking back (borrowing from Mark's post) is not the attempt to "standardize" certain new features for SOAP messages, but the apparent lack (or break-down) of a cohesive guiding principle for architecting SOAP-based web services. I'm referring to WS-ResourceTransfer here.
When I got up this morning, my legs were not feeling so well, and so I expected a slower finish today. For the first twenty miles, I managed a paltry 14.5 mph average. But thanks to a Red Bull, and a few yummy slices of Banana Bread at the aid station in Vader (WA), helped improve the average so much that, at the end of 6 hours and 1 minute, I crossed 100 miles - the best time for a century ride for me so far. However, due to frequent stopping during the last 5 miles, the average fell back to 16.45mph.
With 9500 other riders, from Seattle to Centralia (WA), 100 miles, 6 hours 13 minutes ride time, 7 hours 30 minutes elapsed time.
This is my fastest (and flattest) century ever. My previous century a month ago (Flying Wheels Century) took an hour more, but it also involved more climb.
I wanted to post this comment at Bill's post Tunnel as deployed. But at the time of writing this, that page was giving me a 404 (I could only read about this post on the index page of his blog) and so, I am posting a quick reply here.
This is in reference to my previous post. If the only clientele for the server is HTML forms based clients, and if the only intent is to work-around the limitations of forms, then the Rails "hack" does not do any good other than introducing a bit of extra complexity into code.
But if the goal is support a vast majority of clients some of which can not support the right thing, then of course, it makes sense to support such "work-arounds".
Here is an addition to the list of anti-patterns that Stefan recently posted. The pattern is to let the client "think" that is using verbs other than GET and POST, but piggyback such requests over GET or POST. This was originally started by the GData folks via the X-HTTP-Method-Override header. Rails came along and baked its version for faking PUT, and DELETE over POST.