[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Enhancement proposal for the CardSync protocol
|
Hi,
In that extend, the approaches of XDI messaging and XCAP are quite
similar, as Markus said.
Now, I think that if the Cardsync protocol uses XML to transport the
message data, then XCAP can be used to improve the protocol's
efficiency. Indeed, it will be easy to map XCAP to an XDI equivalent
if an XDI backend is used.
Antoine
2009/4/18 Markus Sabadello <msabadello@xxxxxxxxxxxxx>:
> Yes I've been thinking the same thing since this thread started. XCAP seems
> to be to XML what XDI Messaging is to XDI itself.
>
> For example, if a card in the back-end was represented like this: (In X3
> Simple format)
>
> $cardid!2273829
> +name
> "My Card"
> +name+issuer
> "Higgins"
> +image
> "AB762F672F3BFA7BFE672FB76BAEFB2624917...."
> $d$lastupdate
> "2009-04-08T12:13:14Z"
> +claims
> /
> +(http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname)
> +name
> "First Name"
> +description
> "First Name"
> $value
> "Drummond"
> ... other claims here ...
>
> Then you could update a part of that card by sending an XDI message like
> this:
>
> =sender
> $mod
> /
> $cardid!2273829
> +name
> "My Renamed Card"
>
> You just update the part of the data you need instead of sending the whole
> thing.
>
> Markus
>
> On Sat, Apr 18, 2009 at 1:42 AM, Drummond Reed <drummond.reed@xxxxxxxxxxxx>
> wrote:
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>
>
