[oslc] What should be included in an OSLC SDK Consumer Library?

Dave snoopdave at gmail.com
Fri Jun 24 15:04:15 EDT 2011


On Fri, Jun 24, 2011 at 2:58 PM, Paul McMahan <pmcmahan at us.ibm.com> wrote:
> Sample js/dojo code for consuming UI Preview and Selection/Creation dialogs
> might also be useful.

Good point. In the plan, I proposed OSLC Client Libraries for:

   - Java
   - PHP
   - JavaScript

The JavaScript client should include some of the same things as the
Java and PHP clients, but there would be some differences, see below.
I think we need some more thought on the notion of a JavaScript client
library.

   - JavaScript client can't handle OAuth on it's own, would need some
server-side help
   - JavaScript client could include helper code for UI Preview and Delegated UI


Thanks,
Dave




> From:   Dave <snoopdave at gmail.com>
> To:     oslc-tools-devel at lists.sourceforge.net,
>            community at open-services.net
> Date:   06/24/2011 02:03 PM
> Subject:        [oslc] What should be included in an OSLC SDK Consumer Library?
> Sent by:        community-bounces at open-services.net
>
>
>
> Here's another topic for discussion from the OSLC SDK proposal.
>
> https://sourceforge.net/apps/mediawiki/oslc-tools/index.php?title=Proposal_for_OSLC_SDK
>
>
> Here are some ideas for what should be in an OSLC SDK Client Library:
>
> * HTTP Client
>  - Must support for OAuth and BASIC Auth
>  - Include and build on an existing open source HTTP client
>  - Add or augment client's OAuth and BASIC auth support
>
> * RDF toolkit
>  - Must support parsing and generating RDF/XML
>  - Include and build on an existing open source RDF toolkit
>  - Add ability to parse and generate OSLC JSON format
>
> * OSLC "object model" or some way to:
>  - Make it easy for folks to create and general OSLC resources
>  - Make it easy to get resources as objects with properties
>
> * Other ideas for client library features:
>  - Ability to validate a resource against a Resource Shape
>  - Ability to easily iterate through multi-page resources
>  - Ability to determine Creation URL to use for given resource type
>  - Ability to determine Query URL to use for given resource type
>
> * Documentation
>  - Overview and how-to sections for C.R.U.D. on resources
>  - API reference for any objects and properties introduced
>
> Does that sound like the makings of a Client Library? What else should
> be present?
>
> Other issues...
>
> For other platforms such as PHP, Python, Ruby, etc. what are the best
> choices for HTTP clients and RDF toolkits?
>
> Which of the "other platforms" are most important for OSLC adoption?
> Is PHP the #1 priority or Ruby, or Perl?
>
> Other ideas?
>
> Thanks,
> Dave
>
>
> --
> David M. Johnson
> OSLC Specification Lead
> IBM Rational Software
>
> _______________________________________________
> Community mailing list
> Community at open-services.net
> http://open-services.net/mailman/listinfo/community_open-services.net
>
>
>




More information about the Community mailing list