Hi All,
We are looking at simplifying the query protocol used to interact with our TS service. Currently, it is pretty much the same protocol as is used to the LS so it has some bearing on the discussions in NMC. I don't believe NMC has taken up the effort to standardize the TS interactions yet, but it is obviously something we should look at once the 'Base' docs have been submitted.
In any case, it would be helpful to get feedback from you all on these ideas.
jeff
Begin forwarded message:
> From: Roman Łapacz <romradz(a)man.poznan.pl>
> Date: January 27, 2011 7:41:06 AM MST
> To: Aaron Brown <aaron(a)internet2.edu>
> Cc: Andrew Lake <andy(a)es.net>, i2-perfsonar(a)internet2.edu
> Subject: Re: [I2-perfSONAR] TS modification proposal
>
> W dniu 2011-01-26 15:06, Aaron Brown pisze:
>> On Jan 25, 2011, at 4:01 PM, Andrew Lake wrote:
>>
>>> Hi Aaron,
>>>
>>> I like the idea of condensing the protocol down to something simpler like XPath. If we are going to take a step like this, I think it might also be worth exploring non-XPath options as well. For example, could we break the queries down into a series of well-defined XML elements that compose the query? This could have the advantage that rather than our schema documents just having a string field where you stick the Xpath we'd have some elements defined to specify things like return type (e.g. domains, nodes, ports, or links), query constraints (e.g. id== x, bandwidth>= 3Gbps, etc). Those are just examples off the top of my head so we'd have to think through all the options. This could allow us to enforce a constrained set of queries easier and in a way more transparent to a user than coming up with an XPath subset. It may prove that our use cases make such a schema too complicated, but I think it might be worth thinking about as part this effort.
>
> This could be also suitable for LS queries. Could the OGF NMC mailing list be CCed in this discussion?
>
> Cheers,
> Roman
>
>
>> We could probably sit down and try to come up with use-cases and/or examples at Joint Techs.
>>
>> Cheers,
>> Aaron
>>
>>> Andy
>>>
>>> On Jan 25, 2011, at 3:22 PM, Aaron Brown wrote:
>>>
>>>> All,
>>>>
>>>> As part of the circuit monitoring work, I'm making modifications to the topology service to support the new topology format. Currently, the query method is XQuery, but in looking at the types of requests that get sent to the TS, most are XPath, or could be handled by XPath. With that in mind, I was thinking it might make sense to modify the TS protocol to use a limited XPath instead of XQuery. Using XPath statements has the benefit that it is reasonably straight-forward to convert XPath statements to work against a different backend (e.g. a SQL backend, or whatever). Presumably, it'd make sense to only specifically support a subset of the XPath syntax to make it easier to use against different backends.
>>>>
>>>> In terms of changes to the TS, supporting XPath doesn't require any major changes. We'd need to change the protocol to accept the XPath statement, and then have a system to validate the XPath (to make sure it's only the subset or whatever). Sleepycat XML DB accepts XPath expressions directly so the TS wouldn't need any changes to handle that.
>>>>
>>>> As part of this modification, I was thinking of switching the query response slightly. Currently, the response to queries combines all the results into a single datum. By splitting them out, it makes it easier to differentiate non-XML results (e.g. give me the descriptions of all ports). Not a big change, and probably not all that big a deal either way.
>>>>
>>>> Cheers,
>>>> Aaron
>
>
