Re: [higgins-dev] Enhancement proposal for the CardSync protocol

[Antoine Fressancourt <af.devlist@xxxxxxxxx>]

Hello Markus,

Nice to share some thoughts with you on the list! Regarding the Iphone
selector, I somehow have a problem on my computer with the Iphone
developer certificate, and I didn't have that much time to work on it
since your visit in Paris. But I am not the kind of guy who let things
go that easily ;-)

I have read your answer quite carefully, and I don't really agree with
your conclusions on the use of the XCAP protocol. Indeed, in its
typical use case, XCAP is used only to act on informations which may
not be stored as XML files in the backend. In a presence service using
XCAP to set filtering rules. These rules may not be stored in XML
format. The purpose of this syntax is to reduce the length of the XML
document sent in the requests in order to ease the transmission of the
message and the parsing operation of the XML document when it is
received, as the modification is clearly spotted in the XCAP URI.

I understand that this may not be your first priority to date, but I
am quite sure that the use of this protocol can ease the operation of
the cardsync protocol later, especially on the server where XML
parsing operations can be time consuming.

Antoine

2009/4/13 Markus Sabadello <msabadello@xxxxxxxxxxxxx>:
> Hi Antoine,
>
> Nice to see you on the list :)
> I've never heard of XCAP, but I just went through that PPT. It looks like a
> great technology.. It seems to be very suitable when you have backend data
> in XML format and want to expose that data.
>
> In the CardSync protocol however, we don't really have XML data in the
> backend. We only use it in the protocol. RPPS stores cards in a database,
> not as .crd files. Also, in the "Update Card" message
> (http://wiki.eclipse.org/CardSync_JAX-RS_API#Update_ICard), the XML format
> is different from the .crd format of a card.
>
> So I think XCAP would be overkill here. But I'm not sure, maybe Alexander
> has a different opinion (he mostly designed CardSync).
>
> BTW Antoine, any news on the iPhone Selector? Did you try to build it
> yourself?
>
> Markus
>
> On Thu, Apr 9, 2009 at 3:46 PM, Antoine Fressancourt <af.devlist@xxxxxxxxx>
> wrote:
>>
>> Hello list,
>>
>> I am a R&D engineer from Atos Worldline, one of the companies involved
>> in the FC² project in France. We had the opportunity and the chance to
>> meet with Paul Trevithick and Markus Sabadello in France during a 3
>> days meeting in April when some details about the Higgins project and
>> the components architecture were presented to us. During this meeting,
>> we learnt about the cardsync protocol, which is an XML document
>> exchange using a RESTful interface.
>>
>> I have a suggestion to make about this protocol. In the wiki
>> documentation, the messages exchanged to create, update or destroy a
>> card in the cardstore. Indeed, I am a bit sceptic about the method
>> used to update a card. From my understanding, when somebody wants to
>> update an information on a card, he has to send the whole content of
>> the file in XML, with the update included. It seems to me that this
>> procedure could be enhanced by using XCAP.
>>
>> XCAP stands for XML Configuration Access Protocol. Basically, this
>> protocol allows a person interested in a particular data in an XML
>> document to access it directly. The path of the XML node in the
>> document is mapped to an URI, which can be used to create, update or
>> destroy the node. As I am sure this explanation is not enough for you,
>> I can indicate you an excellent XCAP tutorial written by the principal
>> author of the XCAP RFC.
>> http://www.jdrosen.net/papers/xcap-tutorial.ppt
>>
>> Currently, this protocol is used in Telecommunication services such as
>> Presence service or contact list management in order to maintain
>> contact lists or user profile in a central node called the XML
>> Document Management Server. As this server has about the same role for
>> these services as the CardStore in the Higgins architecture.
>>
>> I make a suggestion here, and I would be pleased to answer your
>> remarks or questions if you have some.
>>
>> Best regards,
>>
>> Antoine Fressancourt
>> _______________________________________________
>> higgins-dev mailing list
>> higgins-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>