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:all-tabpanel ]

Martin Pain  updated OSLCCORE-9:
--------------------------------

    Description: 
See https://lists.oasis-open.org/archives/oslc-core/201503/msg00016.html

The problem is about the user experience's when configuring OSLC clients to connect to OSLC servers. I think having to search a server's documentation and UI to find a discovery URI that is used only once is not a good user experience, and this will come very early in new users' experimentation with OSLC (both developers and administrators).

The resource the client wants is the "root" ServiceProviderCatalog. The user will be aware of the idea of URIs representing resources, but the resource in their mind is the server, and the URI they associate with the server is most likely the home page of its web UI. So I suggest we define a Link header rel that is used to link that web UI URI to the ServerProviderCatalog URI.

So then the user's experience will be:
- They are reading the client's instructions for integrating with OSLC servers.
- It says to enter the URI to the server's home page.
- The user copies that from their browser and enters it into the client.
- The client finds what it needs on the server. (Under the covers: they do a OPTIONS request on the URI that was provided, follow the Link header that has the rel that we define, and request that URI with an Accept header for the content types that they support, and receive the root ServiceProviderCatalog).

**(The original proposal has been moved to a comment on 24th July 2015 to avoid confusion with the revised proposal that is in the "proposal" field above.)**

  was:
See https://lists.oasis-open.org/archives/oslc-core/201503/msg00016.html

The problem is about the user experience's when configuring OSLC clients to connect to OSLC servers. I think having to search a server's documentation and UI to find a discovery URI that is used only once is not a good user experience, and this will come very early in new users' experimentation with OSLC (both developers and administrators).

The resource the client wants is the "root" ServiceProviderCatalog. The user will be aware of the idea of URIs representing resources, but the resource in their mind is the server, and the URI they associate with the server is most likely the home page of its web UI. So I suggest we define a Link header rel that is used to link that web UI URI to the ServerProviderCatalog URI.

So then the user's experience will be:
- They are reading the client's instructions for integrating with OSLC servers.
- It says to enter the URI to the server's home page.
- The user copies that from their browser and enters it into the client.
- The client finds what it needs on the server. (Under the covers: they do a OPTIONS request on the URI that was provided, follow the Link header that has the rel that we define, and request that URI with an Accept header for the content types that they support, and receive the root ServiceProviderCatalog).

*(The original proposal has been moved to a comment on 24th July 2015 to avoid confusion with the revised proposal that is in the "proposal" field above.)*


> 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
> The problem is about the user experience's when configuring OSLC clients to connect to OSLC servers. I think having to search a server's documentation and UI to find a discovery URI that is used only once is not a good user experience, and this will come very early in new users' experimentation with OSLC (both developers and administrators).
> The resource the client wants is the "root" ServiceProviderCatalog. The user will be aware of the idea of URIs representing resources, but the resource in their mind is the server, and the URI they associate with the server is most likely the home page of its web UI. So I suggest we define a Link header rel that is used to link that web UI URI to the ServerProviderCatalog URI.
> So then the user's experience will be:
> - They are reading the client's instructions for integrating with OSLC servers.
> - It says to enter the URI to the server's home page.
> - The user copies that from their browser and enters it into the client.
> - The client finds what it needs on the server. (Under the covers: they do a OPTIONS request on the URI that was provided, follow the Link header that has the rel that we define, and request that URI with an Accept header for the content types that they support, and receive the root ServiceProviderCatalog).
> **(The original proposal has been moved to a comment on 24th July 2015 to avoid confusion with the revised proposal that is in the "proposal" field above.)**



--
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]