Hi. Le lundi 27 juin 2011 à 10:02 -0400, Dave a écrit : > There are a couple of different ways to think about the OSLC reference > implementations and some conflicting goals, depending on how you > think. I think it's useful to consider the different ways to think > about the SDK's provider implementation(s), so here are three: > > > 1) Reference Implementation: Think of RIO as a reference > implementation, design to support the needs of workgroups developing > specs and experimenting with new features, protocols, etc. > * Goals > - Support spec development process > - Provide complete and correct implementation of OSLC specs > - Experimental "prototype" for proposed spec features > - Provide example code for developers implementing providers > - Make it very easy for workgroups to build implementations > e.g. data-driven implementation, use of RDF triple store, etc.
I'd add that it comes together with a (high-level) test suite that can be used to test other provider implementations. It it's a correct implementation and such tests fail on other providers, chances are that these are buggy ;) > * Non-goals > - Useful as an ALM tool > - Production ready and high performance > * Issues > - Easy for OSLC workgroups is different from easy for product > developers, and product developer care a lot about being production > ready and high-performance, so this approach won't help product > developers looking for example code and re-usable components. > > > 2) Provider Framework: Think of RIO as a framework for building OSLC > providers, design to support the needs of product development teams > who are adding OSLC support to existing products. > * Goals > - Provide framework for building Provider Implementations > - Suitable for creating complete and correct implementation of OSLC specs > - Suitable for creating production ready implementation of OSLC specs > - Make it easy for product teams to add OSLC support to existing products > * Non-goals > - Useful as an ALM tool > * Issues > - Developers already use a lot of different web development > frameworks. Do we really want to introduce a new framework for > REST/Linked Data services? Won't this cause problems for those already > using other web/REST frameworks such as Spring, JSF, Seam, Wicket, > Struts, Play, JAX-RS, etc.? We may expect more existing (or new) Open Source ALM tools developing OSLC-compliant modules. If they share their code as Open Source, there's no need for such a framework, then. Reusing non-reference, but existing code is the way to go for implementers. But then, there's again the need for reference tests to be passed by tools in order to be able to assess their compatibility before reuse. Still, in such a schema, one has to initiate the process or publising Open Source OSLC compliant ALMs, for each popular language/technology. So, for instance, if it is considered strategic for some actors to develop, say, JAX-RS based adapter for webservices, then let have them do it and rejoice ;)... still, I don't think this would qualify for a RI (even if this can be great). FWIW, our current codebase in PHP (Zend Framework) initially developped for MantisBT, then ported to FusionForge, somehow fits this kind. > > > 3) Pluggable Adapter Implementation: Think of RIO as an Adapter Server > that can be used to create an OSLC provider by "plugging in" a backend > system. This is very similar to the "Shindig" reference implementation > for OpenSocial. > * Goals > - Complete OSLC adapter that allows back-end to be plugged in > - Suitable for creating complete and correct implementation of OSLC specs > - Suitable for creating production ready implementation of OSLC specs > - Make it easy for product teams to add OSLC support to existing products > * Non-goals > - Useful as an ALM tool > * Issues > - There are some significant problems with the adapter approach, > e.g. introduction of redundant URLs for resources, new server to be > maintained, etc. > > > Personally, I think we want #1 and #3 above. Definitely #1 and test suite ;) > > Regardless of how we think of RIO, I think the OSLC SDK should include > a Provider Library, a set of components, utilities and helper classes > for building OSLC provider implementations. iterated for every popular language ? > * Goals > - Provide specific components useful for building OSLC providers > - e.g. Query Syntax parser, OSLC JSON parser/generator > - Suitable for creating complete and correct implementation of OSLC specs > - Suitable for creating production ready implementation of OSLC specs > - Make it easy for product teams to add OSLC support to existing products > - Works equally well with any web development framework > > > Other thoughts? What type of provider implementation(s) would you like > to see in the OSLC SDK? > > Thanks, > Dave My 2 cents, -- Olivier BERGER <[email protected]> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
