[Nmc-wg] Fwd: [I2-perfSONAR] TS modification proposal

[Roman Łapacz]

W dniu 2011-01-27 17:43, Jeff W. Boote pisze:
> 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.

I think that it would be good to proceed the way like it is for circuit 
monitoring. Start with some simple example(s)  and use case(s) (Aaron 
mentioned that) and work on them (in fact, the logic behind them) 
together until the final broad agreement.

cheers,
Roman

>
> jeff
>
> Begin forwarded message:
>
>> *From: *Roman Łapacz <romradz at man.poznan.pl 
>> <mailto:romradz at man.poznan.pl>>
>> *Date: *January 27, 2011 7:41:06 AM MST
>> *To: *Aaron Brown <aaron at internet2.edu <mailto:aaron at internet2.edu>>
>> *Cc: *Andrew Lake <andy at es.net <mailto:andy at es.net>>, 
>> i2-perfsonar at internet2.edu <mailto:i2-perfsonar at 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
>>
>>
>
>
> _______________________________________________
> Nmc-wg mailing list
> Nmc-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nmc-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nmc-wg/attachments/20110128/24a6afa2/attachment.html