|
|
|
 |
Thursday, April 11, 2002 |
Patterns of Change. An essay about change. Forgive the grammar issues, it's late and I don't feel like being picky about my writing style.
10:20:15 PM 
|
|
Scripting News: "Something James Snell and I agree on." Dave and I agree on something! Now THAT'S big news. :-)
7:03:52 PM
|
|
Here's a bootstrap opportunity. The latest version of the Web Services Toolkit (released today) includes a Web service interface definition for doing CRUD (Create/Read/Update/Delete) operations against any type of back end datastore and a simple implementation that uses the API to edit simple XML files. The API itself (called the "Common Data Service" or CDS for short) isn't much different than what Hailstorm used, or what Ruples and XSpaces use. The opportunity here is simple: You can implement the CDS interface. The reason it exists is to help bolster the idea that Web service utilities can be implemented easily and quickly using standardized interfaces. XSpaces and Ruples could easily implement this API so that they become completely interoperable with one another. Google could implement the API to provide a two-way dialogue with applications like Radio. Userland could implement the API on top of it's XML data store. Apache's Xindice could implement the API also. The API could be used to create the types of shared memory spaces Jon and Sam have talked about. I've implement test versions of the API (nothing I can release right now though unfortunately. perhaps in the not too distant future) using SOAP, HTTP-GET, HTTP-POST, XML-RPC, WebDAV, and Jabber. (note: the toolkit only contains the SOAP over HTTP flavor).
As people implement it, I would like them to provide me feedback and I'll make the necessary changes to improve it. The spec included in the release is not complete (lots of todo's still), but will be updated in a future point release.
Have fun.
6:56:01 PM
|
|
Think Bigger. (bigger does not mean more complex)
5:00:12 PM
|
|
Ok, so the Google API allows you to search google with SOAP. No big deal. What would really be interesting is if it was a two way thing. You know, I own content on the net. Google maintains a directory of that content. Google let's me notify it when that content changes, a simple ping that says "Hey, I just updated my web page! Process the changes and update your database please!". Better yet, allow me to also tell google how to categorize my content. Sure, google would still be able to do it's own automatic categorization thing, but when I tell google my content has changed, let me also say that "Hey, this is a Web services related thing so list it under your Web services category". Even better yet, allow me to create subscriptions to the google database. When the entry for a given site is updated, google gives me a ping. This could work for searches too. I send a search query with a callback address. Rather than getting results back right away, I get results back on an ongoing basis as sites are found that match the query.
I'm sorry, I know everyone is really excited about the new Google API, and I've gotta say that it is cool to see this stuff being used. It really is a great first step and I applaud google for taking it. But allowing us the ability to search google using a SOAP request hardly qualifies as revolutionary. Make it two-way, and now you've got something big.
Here's another idea (less related to Web services): integrate google and blogs and I/O so that discussions about Web content can be maintained in context. For example, if I create a blog entry and google picks it up, and somebody discusses my entry either on their blog or in their instant outline, when somebody finds my entry using a google search, they also find all of the blog/outline discussions about my entry. In other words, in addition to the "Cached" and "Similar Pages" option that google gives you, there would be another link for "Discussions" that would list all of the blog entries, etc.
Ok, one more idea (last one of the day). When I visit the news aggregator page in Radio, it would be cool to have a "Google Finder" option for each news item that would do a search on topics related to the news item.
4:58:26 PM
|
|
1.5 ....
11:45:34 AM
|
|
Dave: "Come back here in a few minutes for some really big news." Dave is almost as bad as the nightly news broadcasts, "Something really big happened today, news at 11!" Oy... out with it man!
11:42:51 AM
|
|
Simon Fell: "Hey James relax, I'll try and remember to put smileys on my posts next time :)" Vacation, vacation, vacation, vacation, vacation, va........
8:30:26 AM
|
|
Simon Fell: "Microsoft, I.B.M. and VeriSign to Cooperate on Web Security. Microsoft, I.B.M. and VeriSign plan to announce a new technical approach that they hope will ensure greater security and thus stimulate commercial development of Web services. By Steve Lohr. [New York Times: Technology] Sounds like there's going to be a new version of WS-Security coming down the pipe."
IBM developerWorks
This is a new Web Services security proposal that combines the SOAP-SEC and WS-Security/WS-License stuff that was out before.
8:29:02 AM
|
|
Simon: Evolving Interfaces : "This takes the COM versioning model and applies to Web Services. As an old school COM guy, this makes sense to me, however, Microsoft themselves have ditched COM's versioning model (and lets face it, they were always the biggest culprits in not following it), the versioning model in the CLR allows for more interesting versioning scenarios, I'm surprised that they think the COM model is fine for Web Services. I agree with James's comment that types should be revised using XSD's derivation support. In answer to Sams' question about ASP.NET, I think the reason why ASP.NET just applies defaults has nothing to do with versioning, but was a simple speed/functionality trade-off. Its a pity that you don't get the option in ASP.NET to enable validation if you want it (Hey, Keith, this is on the todo list right ?). I believe that the version model Sam is pushing for makes a lot of sense, and feels more like the XML way, it'd be an interesting exercise to see if this is possible in any of the current toolkits."
I should have been more clear (Sam is right, I DO need a vacation), it's not the COM versioning model that I support, it's the treatment of WSDL as an interface description that must be versioned, and must be treated with care over successive generations. A PortType is an interface. It is a contract. As with any contract, there needs to be mechanisms in place to make sure that when a change is made, it's done in a way that's not going to break a bunch of existing code. The approach Sam takes is one way to realize this.
And oh, btw,
2....
8:16:59 AM
|
|
|
|
