I don't get it here. The subject of the mail talks about a checkin operation, the body of the email talks about checkout...
> Adobe Drive 2 does the following when you request a checkout: > POST /.../repo/checkedout If we talk about checkout, I am not sure why the client sends a content link. This would be pretty useless in this case, because creating the PWC is only a task for the server. So the question then would be: Do we need to throw an exception for useless information that we get? I think reporting a warning to the log file would be sufficient in this case. However if we talk about a checkin (and the client does not transfer content inline but refers to a foreign destination) then all the issues Florian reports can't be silently ignored... Florent could you clarify the use case? Jens -----Original Message----- From: Florian Müller [mailto:florian.muel...@alfresco.com] Sent: Montag, 22. November 2010 15:45 To: chemistry-dev@incubator.apache.org Subject: Re: AD2 and checkin Hi Florent, I intentionally didn't implement that features because there are too many difficult questions. What basically happens here is that the CMIS repository connects to a HTTP server to get the content. - In many enterprise environments that's not possible because of firewalls. The server can't talk to an arbitrary host for security reasons. - If the content is hosted on a client machine, it is even more unlikely since desktop firewalls will prevent that. - Should the CMIS repository forward the given credentials to the HTTP server? Hell, no, that would be a security hole. But, yes, it has to authenticate in order to get access to the content... - If we forward the credentials, we really, really should use HTTPS. Do we accept self-signed certificates? Probably not. Does the HTTP server running on a users laptop has a real certificate installed? Probably not. - What if the credentials for the CMIS repository and the HTTP server are different? A very likely scenario... - What if the credentials are not user/password based and we can't forward them because we don't know them? I don't know how to provide a generic external content implementation, but I'm open for ideas... - Florian On 22/11/2010 10:44, Florent Guillaume wrote: > Hi, > > Adobe Drive 2 does the following when you request a checkout: > > POST /.../repo/checkedout > Content-Type: application/atom+xml;type=entry > > <atom:entry xmlns:atom="http://www.w3.org/2005/Atom";> > ... > <atom:content > src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"; > type="image/jpeg" /> > <cmisra:object > xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/";> > ... > </cmisra:object> > ... > </atom:entry> > > In particular it provides a content src (the one from the entry > itself), which OpenCMIS doesn't like: > HTTP/1.1 405 Method Not Allowed > > This is due to code in AtomEntryParser.parseAtomContent: > } else if (ATTR_SRC.equals(attrName.getLocalPart())) { > throw new CmisNotSupportedException("External content > not supported!"); > } > > I'm not sure this is the right thing to do here, can we just ignore > this external content? > > Florent > > >
