[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