Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Received-SPF: pass (nike.apache.org: domain of gavin.cornwell@alfresco.com
 designates 207.126.144.117 as permitted sender)
Subject: Re: ObjectiveCMIS browser binding comments
References: <100EABE5-CD25-407F-8930-F44730C241AC@alfresco.com>
 <CF76D048.6BB1%peter.sutter@sap.com>
From: Gavin Cornwell <gavin.cornwell@alfresco.com>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: <CF76D048.6BB1%peter.sutter@sap.com>
Message-Id: <FAC852F0-9477-4DBB-8DFD-7F7CE930753E@alfresco.com>
Date: Mon, 21 Apr 2014 21:31:09 +0100
To: "dev@chemistry.apache.org" <dev@chemistry.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

Hi Peter,

Yep, the two properties on RepositoryInfo are not used currently and are act=
ually stored in the binding session (as they are in the atompub binding) so I=
 would definitely suggest removing them.

Yes, I see the CMISURLUtil is used consistently in all methods, but we are r=
epeating the same code a lot which the builder objects encapsulate. Could we=
 not pass the browser binding specific part of the URL into the builder obje=
ct as the template URL (i.e. the output of the get methods you added to the b=
ase service class) and have the builder object just add the common parameter=
s? Alternatively, we could have a browser binding UriBuilder subclass?

Hope you had a good Easter holiday by the way!

Regards,

Gavin

Sent from my iPad


> On 18 Apr 2014, at 12:01, "Sutter, Peter" <peter.sutter@sap.com> wrote:
>=20
> Hi Gavin,
>=20
> thanks for your feedback. Yes those constants should be move to the
> CMISBroserConstants header file.
>=20
> Yup there should be rather a browser binding subclass for the
> RepositoryInfo that holds those two properties. I will do that (or will
> remove it as those properties are currently not used).
>=20
> In fact when I started with the browser binding implementation I have used=

> the UriBuilder classes where possible but I had to extend them for other
> properties like succinct and so on but I could not reuse those classes for=

> all the methods so I went for the CMISURLUtil which is now used consistent=

> in all methods.
>=20
> Same here in germany with the public holidays, so happy easter holidays :)=

>=20
> Best regards,
> Peter
>=20
>=20
>=20
>> On 4/18/14, 12:02 AM, "Gavin Cornwell" <gavin.cornwell@alfresco.com> wrot=
e:
>>=20
>> Hi Peter,
>>=20
>> You=C2=B9ve made great progress already, I just have a few questions/comm=
ents
>> about the changes made in revision 1588209.
>>=20
>> There are a couple of browser binding constants in CMISConstants.h
>> (kCMISParameterSelector & kCMISParameterSuccinct), can you please move
>> these to CMISBrowserConstants.h?
>>=20
>> rootFolderUrl and repositoryUrl properties have been added to
>> RepositoryInfo. This object should match the definition of RepositoryInfo=

>> in the CMIS spec, furthermore, these properties are browser binding
>> specific and don=C2=B9t appear to be used. I think we should keep this ob=
ject
>> completely generic (as it is in OpenCMIS).
>>=20
>> Is there a reason why you haven=C2=B9t used the UriBuilder objects to
>> construct the URLs in the service methods i.e. in retrieveChildren and
>> retrieveObject?
>>=20
>> Please note it=C2=B9s a public holiday in the UK tomorrow and Monday so
>> responses might be delayed more than usual ;-)
>>=20
>> Regards,
>>=20
>> Gavin
>=20