OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dcml-frame message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dcml-frame] Implementation Subgroup


Good, and I agree that our primary goal is the
spec. I'll make that clear.            -- Tim

Cummins, Fred A wrote:
> Tim,
> 
> I have no problem with some participants working on a
> prototype implementation, as long as the focus and
> principal product of the group is the interface
> standard. I suggest caution in moving too quickly
> to a prototype since that can restrict thinking and
> consideration of alternative approaches.
> 
> Fred
> 
> 
>>-----Original Message-----
>>From: Tim Howes [mailto:howes@opsware.com] 
>>Sent: Tuesday, October 25, 2005 4:57 PM
>>To: Cummins, Fred A
>>Cc: dcml-frame@lists.oasis-open.org
>>Subject: Re: [dcml-frame] Implementation Subgroup
>>
>>Fred, you are completely missing the point. The point is not 
>>to produce THE implementation of DCML. The point is to produce 
>>an EXAMPLE implementation of DCML that will help people 
>>understand the standard, show that the standard is useful, and 
>>encourage vendors to produce products based on the standard.
>>
>>Second, there is no conflict between defining interfaces and 
>>creating an implementation. In fact, you must do the first to 
>>do the second.
>>The advantage of doing them in a parallel, iterative fashion 
>>is that you have a much greater chance of actually getting 
>>your interfaces right if you know they work via implementation.
>>
>>Third, there is a long and highly successful history of 
>>combining standards development with implementation. Namely, 
>>the Internet. That's the model I'd like us to follow. If you 
>>can think of a more successful one, I'm all ears.
>>
>>Fourth, any implementation we produce will be a toy. The point 
>>is not to make something that will compete with anybody's 
>>actual product. But it will serve its purpose, which is 
>>education, awareness, and validation of our ideas. If it 
>>helps, you can think of the example implementation as the 
>>product of one (or a couple, if other people want to help) of 
>>the WG members, rather than the product of the group itself, 
>>which I agree should be the interface definition.
>>
>>Does that make sense?            -- Tim
>>
>>Cummins, Fred A wrote:
>>
>>>Tim,
>>>
>>>I would rather see the product vendors do implementations.
>>>First of all, our implementation would likely be a prototype that 
>>>might not reflect all of the requirements. Secondly, 
>>
>>different vendors 
>>
>>>will have different implementations, and the interface specification 
>>>should enable that differentiation.
>>>I also hope that if we do it right, most vendors will be 
>>
>>able to adapt 
>>
>>>their products to comply rather than developing completely new 
>>>products.  Finally, we should be able to specify reasonably good 
>>>interfaces in much less time than it would take to implement a 
>>>prototype with well-designed interfaces.
>>>
>>>Fred
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Tim Howes [mailto:howes@opsware.com]
>>>>Sent: Tuesday, October 25, 2005 4:01 PM
>>>>To: Cummins, Fred A
>>>>Cc: dcml-frame@lists.oasis-open.org
>>>>Subject: Re: [dcml-frame] Implementation Subgroup
>>>>
>>>>I agree, we need to identify the interfaces. But frankly an 
>>
>>interface 
>>
>>>>in a document is not worth nearly as much as an interface combined 
>>>>with an actual implemtation of that interface. And since 
>>
>>we've already 
>>
>>>>defined the key data interface in the current specification, 
>>
>>we should 
>>
>>>>implement it to see if it works. If it doesn't, or it's the wrong 
>>>>interface, or whatever, we should sharpen
>>>>our pencils and try again.            -- Tim
>>>>
>>>>Cummins, Fred A wrote:
>>>>
>>>>
>>>>>Tim,
>>>>>
>>>>>My expectation was to focus on interfaces to services to achieve 
>>>>>interoperability between products developed by different vendors.
>>>>>OASIS specifications for DCML should define interfaces and product 
>>>>>vendors should define implementations.
>>>>>
>>>>>We should identify and specify priority interface(s) that
>>>>
>>>>have market
>>>>
>>>>
>>>>>value and would be implemented by product vendors.
>>>>>
>>>>>Fred
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Tim Howes [mailto:howes@opsware.com]
>>>>>>Sent: Tuesday, October 25, 2005 3:30 PM
>>>>>>To: dcml-frame@lists.oasis-open.org
>>>>>>Subject: [dcml-frame] Implementation Subgroup
>>>>>>
>>>>>>Hi all. Here's what I think the implementation subgroup that
>>>>
>>>>we talked
>>>>
>>>>
>>>>>>about on today's call should focus on.
>>>>>>Please send me your comments, but this is what I've
>>>>>>had in mind.                             -- Tim
>>>>>>
>>>>>>The implementation subgroup is tasked with creating a freely
>>>>
>>>>available
>>>>
>>>>
>>>>>>open source implementation of a DCML- based solution to the ITIL 
>>>>>>configuration management problem as described by the process
>>>>
>>>>subgroup. 
>>>>
>>>>
>>>>>>The first use case implemented will be one that 
>>
>>incorporates CIM and 
>>
>>>>>>other data sources. This implementation will
>>>>>>provide:
>>>>>>
>>>>>>- a concrete example that furthers people's understanding  
>>
>>of DCML, 
>>
>>>>>>how it relates to CIM, and the problems that  it is meant to solve;
>>>>>>
>>>>>>- example code that will encourage vendors to create  their own 
>>>>>>implementations;
>>>>>>
>>>>>>- a proving ground for changes to our use cases, the  technical 
>>>>>>definition of DCML itself, and the relationship  between DCML and 
>>>>>>other standards.
>>>>>>
>>>>>>The implementation will strive to be of actual use, but more
>>>>
>>>>important
>>>>
>>>>
>>>>>>is its educational purpose. As such, we will strive to 
>>
>>make it very 
>>
>>>>>>easy to download and get started with (e.g., download and
>>>>
>>>>run in less
>>>>
>>>>
>>>>>>than
>>>>>>5 minutes).
>>>>>>
>>>>>>Our deliverables include
>>>>>>
>>>>>>- Detailed description of what we will build
>>>>>>
>>>>>>- Detailed project plan with milestones and dates
>>>>>>
>>>>>>- The software itself
>>>>>>
>>>>>>- Documentation and other materials
>>>>>>
>>>>>>
>>>>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]