[Oslc-Automation] Keeping low barriers of entry - defining implementation archetypes?

[Martin P Pain]

In one of Charles' messages on another thread he mentioned two 
"predominant camps of providers" that might be using that 
feature/scenario.

The purpose of my message about implementation archetypes and profiles was 
to identify if there are any "camps of providers" or "camps of consumers" 
who would be useful to identify so that we could hold these up to each 
scenario we are considering and say "would this scenario work for this 
type of consumer/provider?" (perhaps in each possible combination - i.e. 
"topology" in my earlier message). If it wouldn't work, we would then ask 
"would these provider(s)/consumer(s) want this scenario?" "is there 
another way they can achieve the same thing?" "can they achieve it with 
the existing spec?" (where perhaps the camps being considered so far 
couldn't) and finally "is there a way we could propose this such that 
these consumer(s)/provider(s) could also use it"?

For example, the provider "that are effectively generic with no idea what 
their actions are doing" that Charles identified seem to me much more 
likely to implement the provider-side of the "template" scenario, where 
providers "that are purpose built" for a particular task (e.g. thin 
adapters) are less likely to do so, as they are merely concerned with 
exposing the functionality that they already have. So when we ask "could 
any consumer, when using a 'thin adapter' provider, achieve the templates 
scenario?" the answer is no. The next question is "would they want to?" 
and "is there any way that's possible?". I'll leave those questions until 
we discuss templates again.

So my question for now is: what are the common "camps" of providers and of 
consumers that we already know about?

Martin




From:   John Arwe <johnarwe at us.ibm.com>
To:     oslc-automation at open-services.net, 
Date:   17/05/2013 13:43
Subject:        Re: [Oslc-Automation] Keeping low barriers of entry - 
defining        implementation archetypes?
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



My gut reaction is: sounds complicated.  One of OSLC's features is 
simplicity (relative, no arguments here that today constitutes Simple). 
If this is about which specific combinations of [spec] features are 
implemented, maybe it's a companion document rather than something Every 
Reader Must Wrap Their Head Around. 
Remember that we also have people using Automation in specific areas, and 
some are openly talking about domains "based on" Automation in some way, 
so any complication we introduce at this level potentially hits them as 
well.  It may well also signal that they have the same need, so a common 
solution would be "useful". 
I *like* the idea of carving things into smaller chunks, mind you.  I just 
want to pay attention to the global picture as well. 
Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130523/e9e60337/attachment-0003.html>