[occi-wg] On repainting the bikeshed at the 11th hour...

[Sam Johnston]

Including the list this time...

On 5/7/09, Sam Johnston <samj at samj.net> wrote:
> So examples of the requisite extensibility include creating complex
> storage and networking resources and importing the (large) existing
> base of compute resources (in OVF or other legacy formats). It is
> without doubt better to have the option and not use it than give it up
> and find we need it.
>
> For the componentisation of implementations, it's highly unlikely that
> the best architecture is to use the same platforms for everything from
> controllers to monitoring to billing to security etc. in which case it
> is extremely useful to be able to pass your messages around and build
> them iteratively. JSON is great for [de]serialising objects in memory
> but is actually more troublesome than XML for this particular use
> case.
>
> I guess a lot of this comes down to the public vs private debate that
> Ignacio captured nicely in a recent blog post. I prefer not to
> differentiate and have my money on hybrid architectures. As a
> potential client implementor I'd mych prefer not to have to implement
> OCCi *and* vCloud^W OVF2.0 for things like that function people are
> calling 'cloudbursting'.
>
> With XML we can be light for light users and as fat as need be for the
> more demanding ones (like my enterprise clients who are primarily from
> the CAC 40 - top 40 companies in France).
>
> FWIW I actually dislike XML as much as the next guy but I'm also very
> practical and like to avoid cutting off my nose to spite my face.
>
> Sam on iPhone
>
> On 5/7/09, Mark Masterson <mmasterson at csc.com> wrote:
>> Sam -- for the record, I find blanket assertions such as "an essential
>> enterprise feature" to be problematic.  I'm about as enterprisey as
>> anyone
>> could possibly be, and you are definitely *not* speaking on my behalf
>> here.
>> I've no doubt that you are speaking for someone or something that relates
>> to your experience, and an alternative phrasing such as "an essential
>> feature for the enterprise customers I work with" would clearly
>> articulate
>> that.  But I"m here to tell you -- there's a large and valid population
>> of
>> folk who self-identify as "enterprise" who disagree with much of your
>> reasoning.  Here are some examples:
>>
>> -- "The schema is a WiP for a start, and an essential enterprise
>> feature".
>>
>> No, it is not.  In my world, we are busy trying to learn many lessons
>> from
>> the Web, only some of which fit within the scope of the term REST.  One
>> of
>> the most important lessons we are trying to internalise and apply is that
>> a
>> priori schemas are sometimes much more trouble than they are worth.  In
>> that world, among other things, there are any number of examples of cases
>> where I am trying to figure out how to *store my data* without an a
>> priori
>> schema, because that confers on me all sorts of advantages which seem to
>> move me an inch or two towards the holy grail of disposable software.  I
>> can assure you that, in those sorts of contexts, the idea of going to
>> those
>> lengths, only to move data to and from those schema-less data stores via
>> "standard" mechanisms that impose one of its own can provoke gales of
>> (slightly bitter) laughter.
>>
>> -- "Our success *requires* playing nice with OVF. And SNIA. And probably
>> a
>> bunch of other stuff in the future" followed then by "Our spec will be
>> concise anyway given how we use XML in the lightest way possible".
>>
>> It worries me that you may not see the contradiction lurking in those two
>> statements.  At best, these statements have a high probability of both
>> being true only at a given point in time; one quite early in the life
>> cycle
>> of OCCI (which, of course, is where we are).  Over time, it is *very*
>> unlikely (verging on the impossible, IMO) that both statements can
>> *remain*
>> true.  This is because the imperative underlying each of these statements
>> is in direct conflict with the other -- "playing nice with others" is in
>> direct conflict with "concise".  We all seem to be in agreement about the
>> merits of concise -- the disagreement revolves around the degree of
>> "playing nice with others", and / or preparing for playing nice with
>> others.  I think there is a strong argument to be made for making a
>> deliberate decision, at this point in the lifecycle, to *not* make
>> playing
>> nice with others a goal.  Explicitly -- IOW, making it a non-goal.
>> Instead, focus on what I thought this group was chartered to do -- the
>> simplest possible common representation of what's already out there,
>> working.  The "others" be damned.
>>
>> -- "Cloud architectures are complex with many differs t extensions having
>> to contribute to answers. JSON does not lend itself to this kind of thing
>> so it's actually (a lot) more work for implementors"
>>
>> That sounds, to this "enterprise voice", like a feature, not a bug.
>> Constraints are good.  I like constraints.  You have not yet convinced me
>> that the "extensions" you refer to here are critical to the core of the
>> aforementioned simplest possible common representation of what's already
>> out there, working.  Instead, the impression I get is that these
>> extensions
>> (or even the possibility of having them) serves primarily the "play nice
>> with others" (non) goal.  Since I don't think worrying about playing nice
>> with others is a good idea, imposing a contstraint that makes it harder
>> to
>> do seems like a good idea to me.  Helps focus on the core goal --
>> distractions fall away.  In my experience, that's a design approach that,
>> in turn, produces *very* robust artefacts -- ones on which it is
>> subsequently relatively easy to build more stuff (to play with other, for
>> example).  Doing things the other way round (trying to anticipate and
>> account for possible "extensions"), in my experience, too often leads to
>> fragile, brittle designs.
>>
>> This argument, OTOH:
>>
>> -- "Agreed but that was before we had an almost complete spec, a rough
>> reference implementation complete with mechanical transforms to the
>> requested formats and the start of a HTML interface for good measure. For
>> JSON we have nothing"
>>
>> ... is quite compelling, and in my view.  And that may outweigh all other
>> concerns, given the desire to hold the date.  Dunno.
>>
>>
>>
>> Mark Masterson
>> Enterprise architect, troublemaker
>> CSC
>>
>> Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss
>> Masterson | Public blog: Process Perfection
>> (http://jroller.com/MasterMark/) | mmasterson at csc.com | www.csc.com.
>>
>>
>> CSC • This is a PRIVATE message. If you are not the intended recipient,
>> please delete without copying and kindly advise us by e-mail of the
>> mistake
>> in delivery.  NOTE: Regardless of content, this e-mail shall not operate
>> to
>> bind CSC to any order or other contract unless pursuant to explicit
>> written
>> agreement or government initiative expressly permitting the use of e-mail
>> for such purpose ï CSC Computer Sciences Limited • Registered Office:
>> Royal
>> Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered
>> in England No: 0963578
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>>
>