[occi-wg] moving forward

Sam Johnston samj at samj.net
Wed May 27 04:33:22 CDT 2009


On Wed, May 27, 2009 at 4:31 AM, Benjamin Black <b at b3k.us> wrote:

> On Tue, May 26, 2009 at 6:43 PM, Sam Johnston <samj at 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 at 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 <http://www.doxpara.com/?p=1162> and probably
is with DNSSEC vs DNScurve <http://dnscurve.org/dnssec.html> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090527/c995d284/attachment.html 


More information about the occi-wg mailing list