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