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 <[email protected]>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 <[email protected]>: > > 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 < > [email protected]> > > 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 > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/higgins-dev > > > > > > _______________________________________________ > > higgins-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/higgins-dev > > > > > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
