I agree wholeheartedly with both sentiments. One thing we are trying to do in OGF going forward is to put more emphasis on the implementation communities. How should we organize this for best effect? Would it be better to organize around implementation projects separately, or around technologies for specific standards one at a time (e.g., OCCI, DRMAA, SAGA, BES, JSDL, DFDL, ...), or around whole technology areas as groups (cloud, network, management etc.)? One thing that would be fairly easy to do that would not put an extra burden on each group that is already busy on its own standard sets and specifications would be to clone the structure of the areas at a high level and ask for community implementation groups in that area. This would be the latter of the three alternatives mentioned above. The next level of granularity would be to have an implementation group for each standard that takes care of cataloguing, promoting work on and curating links to implementations of each standard set. (OCCI, etc. as above.) The third level of finer granularity is already provided by the individual implementation projects themselves, for example rOCCI, CompatibleOne, etc. and does not need to be duplicated, obviously. But right now it is very hard for people to find links on the OGF site to any of these or to go further with the use of community-developed implementations of our standards based on what they find in the OGF Redmine, etc. For this reason we can both encourage the use of the wiki, documents and features of Redmine and at a higher level, have added the ability for us to give out accounts to selected groups to host high-level information on the OGF web site. An example (completely built out but not yet linked in at the higher level of the web site) exists for the DFDL group as follows: http://www.ogf.org/dokuwiki/doku.php/standards/dfdl/dfdl We can give out dokuwiki accounts to people on a pilot basis to those who would like to build such sites for their groups on the OGF site, which can include links to implementations, tutorials, getting-started guides etc. and I think it would be a good thing for our areas and groups to have such implementation communities. We can also organize things within the Redmine for easier access without special accounts. (The above pages will eventually be linked at http://ogf.org/dfdl and/or ogf.org/implementations/dfdl for example, replacing the old hand-built pages for this purpose that we used to have, and left under the control of the group.) The basic message here is that OGF would like to promote more work and possibly creation of implementation user community groups, and will provide resources on our web site and other means (e.g., email lists, other communication tools, GitHub sites, etc.) or encourage them to get this to happen. For OCCI, all you have to do to get this to happen would be to tell us what you would like. Alan On Apr 10, 2014, at 7:20 AM, Boris Parak <xparak@mail.muni.cz> wrote:

Hi Jean,

...

OCCI should have its "plug & dev" libraries/framework for building OCCI compliant APIs and extending them.

that's exactly what we are trying to do with the rOCCI framework. It's often presented when talking about OpenNebula and its OCCI support, but the framework itself has no ONE-specific code in it. It is a library for building OCCI compliant services in Ruby.

Cheers, Boris

On Tue, Apr 8, 2014 at 9:23 AM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:

...

Hi all, Regarding the last sentence, I tend to agree, especially for the OCCI: we have a good, consistent and simple API, but it should not be only paper. As SOAP or xmlrpc, OCCI should have its "plug & dev" libraries/framework for building OCCI compliant APIs and extending them.

My 2c Jean

Le lundi 07 avril 2014 à 15:26 +0000, Sill, Alan a écrit :

...

OCCI folks,

I ran into the following paper, also presented as a talk at WS-REST this weekend, and thought you might like to see it. I'd be interested in your response!

Paper: Pragmatic Hypermedia: Creating a Generic, Self-Inflating API Client for Production Use by Pete Gamache, Localytics, Inc. Boston, Massachusetts, USA

http://petegamache.com/wsrest2014-gamache.pdf

Talk: Better Laziness Though Hypermedia

http://petegamache.com/wsrest2014-gamache-slides.pdf

In general, I heard a thread running through the conference of "%$^&*() the API; we just want good libraries." I thought that was a bit disturbing and short-sighted, but understandable, and perhaps could be cured by a better design pattern. Hypermedia seems to be one [possible contributor to better design. Thoughts?

Cheers, Alan

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg