Yes, apologies, I initially used a wrong subject. It's about checkout.

Florent


On Tue, Nov 23, 2010 at 8:06 AM, Jens Hübel <jhue...@opentext.com> wrote:
> Sorry I missed that the thread continued...
>
> If it is checkout then we should be tolerant regarding non-relevant 
> information in the message bodies imho.
>
> Jens
>
> -----Original Message-----
> From: Jens Hübel [mailto:jhue...@opentext.com]
> Sent: Dienstag, 23. November 2010 08:03
> To: chemistry-dev@incubator.apache.org
> Subject: RE: AD2 and checkin
>
> 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
>>
>>
>>
>
>



-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

Reply via email to