Wendy,
On Monday, July 29, 2013, Wendy Roome wrote:
> That works, but would other properties offered by that resource also
> depend on the network map? For example, suppose two different EPS
> resources, using different network maps, both return the "foo" property.
> Would they necessarily return the same value for the same endpoint? Or
> could the values be different?
>
> I think the first interpretation is cleaner.
Agree that they should be the same.
> So if an EPS resource returns
> the "pid" property, it MUST depend on a network map. If an EPS resource
> does not return "pid", it may or may not depend on a network map.
>
> Conceptually that would mean there are N+1 spaces of property names: one
> for each network map, plus one for "independent" properties.
>
> Another approach would be to say to say except for "pid", properties are
> independent of network maps. That would mean that an EPS resource that
> returns "pid" MUST depend on a network map, and MUST NOT return any other
> property. An EPS resource that does not return the "pid" property MUST NOT
> depend on a network map.
>
> I think either alternative is workable, but I think both are a little
> messier than using "pid.network-map-id".
>
>
Let me say a little bit more on my thinking. Personally, I feel that adding
the dependent
resource id as a parameter in the query is more general and flexible.
- For pid, if there are multiple network maps, and the client does want to
specify a network
map that is not the default, the query includes the network map id.
Thinking about your
syntax a bit more, I am starting to feel better, and can justify it, if we
do some reverse (see below):
In particular, I try to draw analogy with SQL syntax. Assume two tables
named netmap1 and netmap2,
in a DB, both with schema (ip, pid). It is ok to write:
select netmap1.pid
from netmap1
where netmap1.ip == query_ip
Note that SQL adds "from" to provide a default name space. Hence, one may
skip the first and third netmap1 in the preceding example.
Hence, I see the following analogy in endpoint property query (see
10.3.1.6):
{
"properties": [ netmap1.pid, "example-prop"],
"endpoints": [ "ipv4:128.1.1.1", "ipv4:136.1.1.1"]
}
with analogy that "properties" specifies the select clause, with
"example-property" in a global table; "endpoints" specifies the where
clause. Note that SQL writes tablename.attr, not the other way -:)
Now, consider the "funny" case of
"properties": [netmap1.pid, netmap2.pid, "example-prop"]
This could theoretically happen as well unless we forbid it.
Now consider the response of the query. The current response can encounter
problems, for example two map-vtags. We encounter this problem because we
want to return the vtag, which is not specified in a SQL syntax. To make
full analogy with SQL, the client should not return the versions, but
we consider a meta reply that always indicate the vtag of used tables.
Hence, I see a response:
"data" : {
"vtags" : { "netmap1": "1266506239", "netmap2":"124657657"},
"map" : {
"ipv4:128.1.1.1": { netmap1.pid: "PID1", netmap2.pid: "pid3",
"example-prop" : " 1"
}
}
Note that we can still specify "uses" with analogy as the SQL "from"
semantics, to indicate the resources used. If there is a uses, the client
is limited to use only the specified resources, still achieving sharding.
- We can work out the details on filtered network and cost maps.
What do you think?
Richard
> - Wendy Roome
>
> >
> >Date: Sun, 28 Jul 2013 11:02:32 -0700
> >From: Richard Alimi <[email protected] <javascript:;>>
> >Subject: Re: [alto] Endpoint property service, network maps and the
> > PID property
> >
> >An alternative would be to use the dependency mechanism in the IRD. Then,
> >if an ALTO Server provides two endpoint property services, it can
> >explicitly define which network map the endpoint property service is for
> >without needing resource IDs to be query parameters filled in by the
> >client.
> >
>
>
> _______________________________________________
> alto mailing list
> [email protected] <javascript:;>
> https://www.ietf.org/mailman/listinfo/alto
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
