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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dam-cmis-profile-discuss message

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


Subject: Re: [dam-cmis-profile-discuss] Key Objectives For CMIS/DAM


Hi Ralph,

Download the "OpenCMIS Server Webapps" [1] package. It contains a CMIS
test repository called the "InMemory repository".
Drop the WAR file into a servlet engine and a few minutes later you have a
local CMIS server to play with. It only needs a servlet engine because it
stores everything in main memory. Obviously, it's not suited for
production, but it's great for testing.

The following URL then takes you to the Browser binding Repository Info.
Open it with a web browser. (It's more fun with a browser plugin that
formats JSON responses.)
http://localhost:8080/chemistry-opencmis-server-inmemory-0.10.0/browser



It will ask you for a username and password. Enter whatever you want.

Find the entries "repositoryUrl" and "rootFolderUrl" in the JSON response.
From there follow the CMIS specification [2] how to build URLs.
The Browser binding allows you addressing objects by object id and path.
All read operations are accessible with just a plain web browser. For
write operations you'll need a REST client that can do HTTP POST (or you
use curl).
You can also find request/response examples here: [3]


Regards,

Florian



[1] http://chemistry.apache.org/java/download.html
[2] 
http://docs.oasis-open.org/cmis/CMIS/v1.1/os/CMIS-v1.1-os.html#x1-5360005
[3] http://docs.oasis-open.org/cmis/CMIS/v1.1/os/examples/browser/




On 27.11.13 18:34, "Ralph Windsor" <ralph@daydream.co.uk> wrote:

>Hi Ray (and others)
>
>Just to get this discussion activated again, one item that would be useful
>from my perspective (and possibly others from the DAM side of things) is
>an
>example of how CMIS object/document metadata is accessed via http but
>without using a library - as discussed in your message below.  So, just
>using something very basic like curl or anything else that can issue http
>requests and display what is returned.
>
>If we had that, we can see then how you might define subsidiary
>definitions
>for various other common DAM metadata protocols and standards (IPTC etc).
>At
>the moment, the conversation is abstract and while we need to get
>objectives
>defined, we also need to connect this back to practical implementation
>issues as the latter will partly inform the former.
>
>I'm expecting that a decent amount of the groundwork for this standard
>will
>in fact be more about educating DAM developers, rather than defining a lot
>of new protocols or extensions thereof (although that will be required
>eventually).
>
>If anyone has a server and is able to set something like this up, that
>would
>be useful.  As discussed, I don't want to do this with anything other than
>basic tools on the client end (although the server generating this could
>be
>more sophisticated).  It's what kind of data a DAM developer interacting
>with CMIS data stores could expect to see.
>
>Anyone who is able to assist, please let me and the list know.
>
>Thanks,
>
>Ralph
>
>
>-----Original Message-----
>From: dam-cmis-profile-discuss@lists.oasis-open.org
>[mailto:dam-cmis-profile-discuss@lists.oasis-open.org] On Behalf Of Ray
>Gauss II
>Sent: 12 November 2013 12:00
>To: dam-cmis-profile-discuss@lists.oasis-open.org
>Subject: Re: [dam-cmis-profile-discuss] Key Objectives For CMIS/DAM
>
>Hi Ralph and others,
>
>One thing to note regarding the perceived difficulty of implementation on
>the part of DAM vendors is that things like the Apache Chemistry libraries
>are by no means *required* for building a CMIS solution, they are simply a
>convenience.
>
>A server-side DAM vendor could choose to craft a response to a CMIS query
>however they see fit, provided the spec is obeyed.
>
>Similarly on the client side, an application is free to make an HTTP call
>directly to a CMIS server, without a library, via the browser binding
>(which
>returns standard JSON) and process that response.  This is very much along
>the lines of what you described when you mentioned an RDFa solution.
>
>Regardless of the format/binding in which the data is passed between
>systems, both must marshall/unmarshall that data, and that is part of the
>convenience the libraries provide.
>
>The EIDR registry [1] for movie and television assets is similar to the
>PLUS
>registry, and those type of globally unique and agreed upon identifiers
>can
>be used in conjunction with repository-specific identifiers.
>
>I think we have done a good job outlining some of the technical
>possibilities of a DAM standard that could leverage CMIS, but have we
>skipped over defining the goals of such a standard?
>
>Are we strictly talking about communication of binaries and metadata
>between
>systems? If so a simple DAM profile dictating a specific data model would
>probably suffice.
>
>Do we expect to invoke some actions on a DAM server such as requesting the
>transcoding of a video?  If so we're moving into defining the creating of
>renditions and the parameters of such a request, which, in that example,
>would include things like codecs, bit rate, resolution, etc.
>
>I'd love to hear from the group on some of the high level use cases we'd
>like to see addressed by this standard.
>
>Regards,
>
>Ray
>
>[1] http://eidr.org/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>dam-cmis-profile-discuss-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail:
>dam-cmis-profile-discuss-help@lists.oasis-open.org
>



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