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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

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


Subject: [OASIS Issue Tracker] (OSLCCORE-9) Bootstrapping discovery


    [ https://issues.oasis-open.org/browse/OSLCCORE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59671#comment-59671 ] 

James Amsden commented on OSLCCORE-9:
-------------------------------------

The biggest difference between OSLC 2.0 and 3.0 is how discovery information is obtained. The actual infomation discovered is similar except for 3.0 does not provide:
 - queryBase - query isn't supported
 - publisher
 - OAuth tokens - 3.0 currently relies on HTTP challenge and response for authentication discovery

Discovery in 2.0 is based on services provided by service providers. OSLC 2.0 discovery provides a summary of the services provided by a service provider (the resources that can be created, queried, selected in a domain), and a list of service providers in a Service Provider Catalog. Clients can access these documents to get information they need to configure their user interfaces and capabilities. Note that these documents are not static. They change as new resources are created in the server (e.g., a new Project Area is created which is a new service provider added to the catalog).

Discovery in OSLC 3.0 is based on capabilities of individual LDP resources. OSLC 3.0 discovery is determined incrementally by doing OPTIONS requests on individual resources and examining returned link headers. There is no central place for discovering what a server can do. Rather this information is determined by OPTIONS requests on LDP resources accessible from the server.

This not only creates incompatibilities between 2.0 and 3.0, 3.0 it may also result in some additional burden on clients to incrementally discovery capabilities with many OPTIONS requests on many resources instead of having that information summarized by the server.

We should discuss this. It might be possible to provide better 2.0/3.0 compatibility by indicating a Core 3.0 server may provide summary information about its resource capabilities in OSLC 2.0 Service Provider Catalogs, Service Providers and Services. These would be dynamically derived from the LDP Containers managed by the server.

> Bootstrapping discovery
> -----------------------
>
>                 Key: OSLCCORE-9
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-9
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Task
>            Reporter: Martin Pain 
>            Assignee: James Amsden
>
> See https://lists.oasis-open.org/archives/oslc-core/201503/msg00016.html
> See also a draft from Mark Nottingham about HTTP home documents: http://tools.ietf.org/html/draft-nottingham-json-home-03 (I haven't read it yet)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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