Re: [apps-discuss] Media type for lists of changed URIs?

[Graham Klyne <[e-mail]>]

On 09/01/2014 14:39, Jan Algermissen wrote:
>
> On 09.01.2014, at 15:29, Graham Klyne <[e-mail]> wrote:
>
>> On 09/01/2014 14:11, Jan Algermissen wrote:
>>>
>>> On 09.01.2014, at 14:37, Graham Klyne <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Maybe ResourceSync (http://www.openarchives.org/rs/0.9.1/resourcesync) has something for you?
>>>
>>> Wow - basically what I am up to. How did I manage to miss it.
>>>
>>> Only thing that's missing, AFAICS, and which  I'll eventually need is the put/patch payload in the change list because in my scenario the number of updates and frequency is too high to justify individual GETs to sync.
>>>
>>> Will take a deeper look anyhow.
>>
>> There are provisions for payload and patch-style operations through resource/change dumps and related-resource links respectively.
>
> Ok, must have missed that at first glance. Either way, pretty exciting you ended up alost exactly where I did.
>
> I have a question regarding a real practical problem from the eCommerce domain:
>
> When eShops send product information to price comparison search engines there is the inherent problem of latency between price updates in the eShop and the re-publishing+ingestion to the shopping engine. If customers find higher prices in the shop, than on the site of the shopping engine, legal fees apply in some countries[1].
>
> Have you ever thought of (or know about plans to) having the major shopping engines adopt resource sync to mitigate that problem? Would lead to a relief of quite some headaches of quite some people I must say.
>
> Given there is sitemap in the mix, I thought Google might have a hand in it somehow.

There are not, to my knowledge, any explicit e-commerce involvements, or plans 
for such, but that's not a deliberate exclusion.  Also, no direct involvement 
with Google AFAIK, but the ResourceSync group did have some discussions with 
some Sitemap people about ensuring consistency of the extensions introduced. 
(Sitemap isn't *only* a Google thing:  cf. http://www.sitemaps.org.)

But the design has attempted to be applicable to web resources in the broadest 
sense.

Specifically, on the issue of synchronization, the design is intended to allow 
the Destination of a ResourceSync change list to be able to determine if it has 
the latest published update.  Some considerable discussion was given to timing 
issues and having confidence that updates could not go silently missing.  But, 
of course, the implementations would be ultimately responsible for ensuring 
changes are pushed out and used consistently.  (E.g. of the Source chooses to 
delay publication of an update, then there's no way for the Destination to know 
about it.)

#g
--



>
> Jan
>
>
> [1] German federal court for example ruled the prices on the site may not be higher because "the customer can expect the systems to be in sync". Which shows an astonishing lack of understanding of the technical domain being ruled upon, IMHO :-)
>
>
>
>
>>
>> Also, the group is currently discussing PubSubHubbub-based notifications to reduce polling load for learning about updates.  The initial draft for that proposal should be public very soon (hopefully days).
>>
>>>
>>>>
>>>> (The data formats used are based on SiteMap/XML rather than JSON as recommended by others in this thread.
>>>
>>> I actuall like XML quite a bit, still.
>>>
>>>> Maybe unhelpful is the current lack of a separate MIME type?)
>>>>
>>>
>>> Well, .... yup :-)
>>
>> I just posed that as a question to the ResourceSync working group.  There's a public discussion list at https://groups.google.com/forum/?fromgroups#!forum/resourcesync
>>
>> This would probably be a good time to get involved with the discussions :)
>>
>> #g
>> --
>>
>>>>
>>>> On 08/01/2014 14:46, Jan Algermissen wrote:
>>>>> Hi all,
>>>>>
>>>>> I am about to work on a media type for transferring lists of URIs of resource that have changed to an 'observer' of a collection of resources.
>>>>>
>>>>> It just occurred to me that something like that might already exist in the context of cache invalidation protocols.?
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>
>>>
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>