Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Enhancement proposal for the CardSync protocol

I’ve been silent on this thread because I’ve been heads-down on behalf of the Information Card Foundation on preparations for RSA, but I wanted to pop up long enough to say that the OASIS XDI TC is very interested in seeing XDI used as a back-end card sync protocol for the same reasons Antoine mentions using XCAP.

 

The XDI TC studied XCAP early in our evolution, and I admire its design. In many ways XDI is like “XCAP for RDF”, which means it has the same generic REST operation capabilities, plus semantic capabilities beyond that of XML, some of which are very well suited to cross-domain data sharing and synchronization.

 

Markus, as the lead developer of XDI4J, is intimately familiar with XDI. You can check out his XDI demonstration utilities based on XDI at http://graceland.parityinc.net/xdi-validator/Other.jsp.

 

I’m happy to provide more information after I resurface after RSA next week.

 

=Drummond

 


From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Markus Sabadello
Sent: Friday, April 17, 2009 6:41 AM
To: Higgins (Trust Framework) Project developer discussions
Subject: Re: [higgins-dev] Enhancement proposal for the CardSync protocol

 

Hi again,

Hmm I see.. Sounds quite convincing. I thought it's only useful when you actually use XML as your backend storage.

Now that I think of it again, it may really make sense to be able to update only a part of the card instead of always sending the whole thing. The question of course is, is it worth introducing the overhead of a new protocol/library.

Alexander? Do you have any opinion on this?

Markus

On Fri, Apr 17, 2009 at 2:58 PM, Antoine Fressancourt <af.devlist@xxxxxxxxx> wrote:

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
>
>
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

 


Back to the top