On Wed, May 27, 2009 at 4:31 AM, Benjamin Black <b@b3k.us> wrote:
On Tue, May 26, 2009 at 6:43 PM, Sam Johnston <samj@samj.net> wrote:

Having worked on this project full time and then some since March I take some amount of offense to your claim that we are "nowhere", especially considering that the proposal you're supporting "as an outsider" to get "somewhere" is the adoption and rubber stamping of your own API (not forgetting that one of the two co-chairs who "strongly supports this course of action" happens to be another Sun employee). If that ends up being the case even in light of the unresolved patent problems first raised over 2 months ago then I'll be out of here quicker than you can say "vendor capture".

i am not now and never have been an employee of sun and i support the adoption of the sun api as the basis for further work.  i care nothing for politics.  it is simply a clean, simple solution to the problem at hand and the very fact that it requires more development makes it perfect for our purposes.

This is an intriguing response given I wasn't referring to you... but it's early and maybe that's not what you meant. If you're looking for a clean, simple solution then I refer you to the wiki where now hundreds of multi-vendor man hours have been spent developing same with what I consider fairly impressive (read "clean, simple") results based on what is out there today.

I guess I missed the memo where running into the usual contention over programmers' preferred formats means we've failed and need to start from scratch. I also missed the part where adopting one vendor's WiP API over any other is somehow fair to other vendors, somehow different from what DMTF are doing with VMware's vCloud API and somehow sensible when we know that Sun have patents like #863157 and #925437 floating around in the problem space - I'd rather just tread carefully than burning more time engaging OGF and/or Sun's lawyers.

A number of us have been closely examining multiple vendors' existing APIs and gleaning from them what is applicable to us - I don't see the need to move this effort in the direction of any one vendor over any other and more specifically I don't see things like fixed classifications schems around Virtual [Private] Data Centers and Clusters are appropriate when there are generic, flexible alternatives. I've also spent more time looking at state machine modeling and discussing it with Roger@Fujitsu in London... while I previously agreed with Tim's case for "actuators" the feedback from the REST crowd left doubt in my mind and I think we may have found a somewhat more flexible approach which provided for audit, canceling unactioned requests, etc.

i have urged you repeatedly in private communications to take a less combative approach and now i am asking you in public.  you are doing little but giving others reason to ignore your views, regardless of their merit.  i see no reason to question tim's motives and many reasons to agree with the api he has helped develop at sun.  please take a step back and see that none of us is in charge here and we all want the best outcome.  the only way we can succeed is together.  we will be right sometimes and wrong sometimes (and sometimes we will be right and do the wrong thing), and that is the nature of standards bodies.

Ok so you told me to "please listen" because the author of various specs was speaking. I did, and I agree with the vast majority of what Tim has to say. You also suggested my message was lost in my delivery, which is probably true - DJB was right about DNS and probably is with DNSSEC vs DNScurve too, but inferior alternatives are still being adopted for a similar reason.

That said, we're working on problems with subtle but important differences - Tim needed to expose the specific functionality of Sun's technology while we need to be more generic, flexible and extensible. We'll pick the eyes out (e.g. take the best parts) of Sun's and GoGrid's and ElasticHosts' and whatever other applicable APIs we can find but if the perfect API existed already none of us would be here.

Sam