Hi,
Please find my response inline.
-Ravi
________________________________________
From: [email protected] [[email protected]] on behalf of Ben
Niven-Jenkins [[email protected]]
Sent: Sunday, March 04, 2012 10:31 PM
To: Martin Thomson
Cc: Sreekanth madhavan; [email protected]
Subject: Re: [alto] FW: New Version Notification for
draft-alto-caching-subscription-00.txt
On 22 Feb 2012, at 16:09, Martin Thomson wrote:
> On 22 February 2012 07:43, Richard Alimi <[email protected]> wrote:
>> Why not? Do you see cases where HTTP's notion of caching is different
>> than what we want in ALTO? (Aside from the caching a part of a
>> response, which Ben has already commented on above..)
>
> If you need to identify subsets of information, then it is quite
> possible that you have too few resources in the design*. A subset
> that is capable of changing could conceivably be identified as an
> independent resource with independent expiration and caching. If you
> want to retain the economy of a single, aggregated resource, you can
> still identify portions within that resource independently. It's
> possible that you would require extensions to the data format to do so
> and there would be tradeoffs in complexity and (maybe) chattiness.
> But you could then build on HTTP caching.
I could see how that could work, PIDs in the network map could be individual
resources and the cost between a PID and other PIDs in the cost map could also
be individual resources.
A network or cost map could contain links to those resources or if an
aggregated map is required the individual resources could be "inlined" to
enable the whole map to be returned in a single response like it can today (see
section 6.4.1 of draft-jenkins-cdni-metadata-00 for a description of one way we
could do it and some hints about an alternative way with slightly different
pros/cons).
An ALTO server could then have a "change feed" resource that is akin to an Atom
Feed that contains links to individual ALTO resources that have changed over
time from some (specified) base map-vtag which clients could retrieve directly
instead of retrieving the entire map each time.
That would appear to work where it is felt acceptable to re-obtain the entire
PID when any change is made to its contents (or to the cost between it and
other PIDs).
Clients could poll the change feed resource using HTTP's If-*-Match semantics
to efficiently ensure they don't have to retrieve & process the change feed
unless the network/cost maps have actually changed.
Ben
[Ravi] The method which is described above is parallel to the one which is
already defined by the base ALTO spec. I don't see the rationale for going for
this method when there is already a filtered map based method defined by the
base ALTO spec. I am not sure if you are suggesting that we do away with the
POST based mechanism completely from ALTO.
The reason why we came up with the ALTO based caching is because of the POST
method that will be used in getting information specific information related to
certain PIDs and this is not cached by the HTTP caches. Going forward we
believe that more and more clients(P2P end points/trackers) will use this
method. In this case the ALTO based caching will be required.
>
>
> One set of tradeoffs has already been made and that produced the
> current design. That doesn't prevent a well-justified and designed
> extension from functioning. There may be a case for optimization.
> But there are probably better ways than inventing a protocol-specific
> subscription extension.
>
> --Martin
>
> p.s. Have you looked at RFC 5989?
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
