On 11/4/13 10:06 AM, "Wendy Roome" <[email protected]> wrote:
>I think we've already lost that battle. First, the client has to >understand HTTP 1.1, including features like chunking. Second, JSON is >simpler than XML, but it's not trivial to parse. We were behind changing from XML to JSON. So, this was a conscious choice. The original protocol was XML based. >Third, the client really >should understand the IRD to select the default network map and associated >cost map resources, because the server may change the resource uris at any >time. And finally, the client should detect duplicate CIDRs. This we should *definitely* fix. If you/folks are at Vancouver we should sit down and try to hash this out. We should have a _always work_, URI, _fall back_ default network and cost map. > >If you really want to simplify things for a sensor, then some other ALTO >client can retrieve the network map from the ALTO server, eliminate >duplicates, recast the network map as (CIDR,PID) pairs, sort by increasing >CIDR length, write the result into a plain text file in some web server, >and give the uri to the simple client. The simple client reads the >(CIDR,PID) pairs and matches against the CIDRs. First match gives the PID. > > - Wendy Roome > >On 11/04/2013 12:37, "Reinaldo Penno (repenno)" <[email protected]> wrote: > >>ALTO client should be dead simple. In the very beginning of ALTO protocol >>Bittorrent folks mentioned that a ALTO client should be able to work by >>simply downloading a text file from a well known URL/IP address and doing >>longest prefix matching so that it could be implemented in the simple >>devices like sensors. This is something I still believe we should strive >>for. > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
