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 <[email protected]> To: [email protected], Date: 17/05/2013 13:43 Subject: Re: [Oslc-Automation] Keeping low barriers of entry - defining implementation archetypes? Sent by: "Oslc-Automation" <[email protected]> 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 [email protected] 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
