Re: [cmis] thinClientURI discussion

[Scott Malabarba <scott.malabarba@us.ibm.com>]

I missed this discussion last Monday, but the feature would be nice to have.

This use case was important with an IBM-internal, CMIS-like interface. As a user, I'm in the more general client app for 90% of my work and it works fine. But every once in a while I need to do something repository-specific. Helps a lot to always have a link I can click on to get to the same document/folder/whatever in the native repository UI, OR in a separate thick client on the desktop (which requires a proprietary scheme).

Florian's implementation idea would work for me.

Regards,
Scott


Peter Monks ---01/29/2014 10:34:23 AM---Yep that'd be fine, although to be honest I suspect it's overkill as most client apps that I've seen

From: Peter Monks <pmonks@alfresco.com>
To: "Huebel, Jens" <j.huebel@sap.com>,
Cc: Jay Brown/Costa Mesa/IBM@IBMUS, "Mueller, Florian" <florian.mueller02@sap.com>, "cmis@lists.oasis-open.org" <cmis@lists.oasis-open.org>
Date: 01/29/2014 10:34 AM
Subject: Re: [cmis] thinClientURI discussion
Sent by: <cmis@lists.oasis-open.org>

---

Yep that'd be fine, although to be honest I suspect it's overkill as most client apps that I've seen wouldn't want to deal with the complexity of multiple UIs - they'd just want the server to tell them which one to use.  No harm (that I can see) in allowing it as a proprietary extension, of course.

A couple of other random thoughts / suggestions:

• URIs need to be per-object, to allow (for example) servers to be able to dynamically calculate which UI URI to server for a given object (e.g. based on the object type, status, location, context, etc. etc.).
• It should be possible to return a URI for any CMIS object, regardless of type (cmis:folder, cmis:document, cmis:item, cmis:relationship, cmis:policy, cmis:secondary etc.).
• URIs may not be http based - it's possible a given server would want to provide URIs with other schemes (e.g. the "app:" URI scheme [1]).  I've not personally seen this requirement mind you, but it seems like something that the spec should support, should this capability be added to it.

Cheers,
Peter

[1] http://www.w3.org/TR/2013/WD-app-uri-20130516/


On 2014-01-28, at 10:51 PM, "Huebel, Jens" <j.huebel@sap.com> wrote:

Would it help to define an additional parameter in this case that can be appended to the URL and filled by the application? Something like &userContext=blessedUI? Something not interpreted by CMIS just passed through? Could also be done via CMIS extensions.

jens


From: Peter Monks <pmonks@alfresco.com>
Date: Wednesday 29 January 2014 00:43
To: Jay Brown <jay.brown@us.ibm.com>, "Mueller, Florian" <florian.mueller02@sap.com>
Cc: "cmis@lists.oasis-open.org" <cmis@lists.oasis-open.org>
Subject: Re: [cmis] thinClientURI discussion

I've fielded this request several times in my work supporting Alfresco integrators.  The general requirement is for the ability for the client app (usually a web app) to be able to reliably "link through" to the Alfresco UI, without having to bake in a bunch of hardcoded, repository-specific, probably version-dependent URL construction logic.

One possible wrinkle is that there isn't necessarily a single UI for the server to redirect the client to.  Alfresco (for example) provides 3 different UIs, and is integrated with several 3rd party UIs that customers may be using exclusively (and therefore may want returned from calls such as this one).  I guess this could be a configurable thing on the server side though i.e. the customer has to pick a "preferred" or "blessed" UI, and that's the single one that would be redirected to via this mechanism.

Cheers,
Peter


On Jan 28, 2014, at 3:19 PM, Jay Brown <jay.brown@us.ibm.com> wrote:

I agree this would be a clean way to do it, but I don't have a use case for this here.  

Perhaps someone else will...


Jay Brown
Senior Engineer, ECM Development
IBM Software Group
jay.brown@us.ibm.com

<graycol.gif>"Mr. Florian Mueller" ---01/28/2014 09:18:54 AM---Hi, In our last call we discussed (and finally rejected) the idea of a thinClientURI that can direct


<ecblank.gif> From:	<ecblank.gif> "Mr. Florian Mueller" <florian.mueller02@sap.com>
<ecblank.gif> To:	<ecblank.gif> cmis@lists.oasis-open.org,
<ecblank.gif> Date:	<ecblank.gif> 01/28/2014 09:18 AM
<ecblank.gif> Subject:	<ecblank.gif> [cmis] thinClientURI discussion
<ecblank.gif> Sent by:	<ecblank.gif> <cmis@lists.oasis-open.org>

---




Hi,

In our last call we discussed (and finally rejected) the idea of a thinClientURI that can directly access the native repository web interface for folders and documents.
Today, I had an idea how this could be done in a very lightweight fashion with (and only) the browser binding.

Browser binding object URLs have a cmisselector parameter. We could introduce a new value for that, for example „native“. It either returns the HTTP status code 307 (Temporary Redirect) with a Location header pointing to the native web interface for this object or the HTTP status code 404 (Not Found) if the repository doesn’t have a web interface or doesn’t want to provide this feature. How the redirect URL is composed is repository specific and could depend, for example, on the object type and on the property values of the object.

Do you think this idea is worth pursuing?


Regards,

Florian