[Nmc-wg] Base doc
Roman Lapacz
romradz at man.poznan.pl
Thu Jan 14 09:13:04 CST 2010
Nina Jeliazkova wrote:
> Roman Lapacz wrote:
>> I like second proposal which groups result codes according to
>> functionalities. It's flexible because it works when e.g. a service acts
>> as ma and mp. I would also add additional category which is not related
>> with a functionality, for example when message parsing fails.
>>
>> 3th proposal is OK as well. Less preferable then 2nd but I'm fine with
>> it if 3th will have more supporters.
>>
>> Roman
>>
> I'm fine with 2nd and 3rd proposal as well. I might already have
> said on the perfsonar list, 1st and 2nd proposals are designed from
> the point of view of a server developer.
>
> >From the client side, if the result codes are only expected to be
> displayed to the human users, and not triggering a client action, it
> doesn't really matter which proposal will be adopted.
>
> If, on the other hand, an automatic client action is expected, then it
> is crucial to know if the reason of the failure is server side, or
> client side (e.g. client submitting wrong data , which can be fixed
> and resubmitted).
On the other hand, could we say: client can send anything and it's the
matter of a service what is accepted. So in this case there are no
server and client errors. Just errors. If a services does not support a
request then it generates 'parse error' or 'unknown request error'.
Roman
>
> Best regards,
> Nina
>> Jeff W.Boote wrote:
>>
>>> Thanks Slawomir.
>>>
>>> It would be great if people could either respond to this thread with
>>> their opinions on the proposed solutions, or be on the call/VC so we
>>> can come to some resolution on this topic.
>>>
>>> thanks,
>>> jeff
>>>
>>> On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
>>>
>>>
>>>
>>>> Hi all,
>>>>
>>>>
>>>> On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
>>>>
>>>>
>>>>> Hi Roman;
>>>>>
>>>>> Thanks for the feedback, comments inline:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> some first comments/observations:
>>>>>>
>>>>>> - I think the structure of namespace could be explained
>>>>>>
>>>>>>
>>>>> The original thinking was the NM-WG document, "An Extensible Schema
>>>>> for
>>>>> Network Measurement and Performance Data", would contain the entire
>>>>> explanation of namespaces (the idea itself coming from another OGF
>>>>> WG).
>>>>> Any future documents from related projects (NMC, NML, others?)
>>>>> would
>>>>> reference this and only note caveats to the original rule. The NM-WG
>>>>> doc is here:
>>>>>
>>>>> https://forge.gridforum.org/sf/go/doc15649?nav=1
>>>>>
>>>>> And I think namespaces are in section 4. Does everyone think this is
>>>>> sufficient, or should we consider other options?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - example of status response in 4.1 does not explain too much
>>>>>> (looks the
>>>>>> same as earlier response example)
>>>>>>
>>>>>>
>>>>> Now that things are in SVN, could you suggest a more fitting example?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - in 4.3.2.6 the concept of key could be explained more (for me
>>>>>> the key
>>>>>> represents some bigger information structure; reasons: performance,
>>>>>> simplicity)
>>>>>>
>>>>>>
>>>>> Good ideas, I will note these.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - in 4.3.2.7 the reference to "Characteristic" document is missing
>>>>>>
>>>>>>
>>>>> Good catch, I will add a real reference.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - I'm wondering whether we can say in 4.3.3 that the request with
>>>>>> more
>>>>>> data triggers includes logical independent sub-requests
>>>>>>
>>>>>>
>>>>> The concept of chaining is also something that Martin and I have
>>>>> struggled to find a proper location. Chaining is explained in
>>>>> sections
>>>>> 5 and 6 of the above NM-WG document currently. I think the basics
>>>>> should remain in NM-WG since the concept of the chain is essential to
>>>>> the definition of data and metadata. We may be able to reference the
>>>>> basic concept though to motivate some of the more unique cases.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - 4.4.1: typo "request schema"
>>>>>>
>>>>>>
>>>>> I will correct.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - I would remove parameter elements "supportedEventType" from all
>>>>>> message examples. I understand that it's supported by the
>>>>>> implementations but it's agreed to use eventType element
>>>>>>
>>>>>>
>>>>> I don't think this is a big deal, since these are just examples. I
>>>>> can
>>>>> remove them if we think it will cause confusion.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - I think we have to rebuild Result Code section and finish the
>>>>>> discussion on new ideas proposed by Slawek and Jeff. That's very
>>>>>> important and must be done.
>>>>>>
>>>>>>
>>>>> This would be the current venu to do so. Has Slawek updated his
>>>>> document based on the suggestions that were made before the holidays?
>>>>> Perhaps he can send it again?
>>>>>
>>>>>
>>>> Yes,
>>>> file is in attachment
>>>>
>>>> Regards,
>>>>
>>>> Slawek
>>>>
>>>>
>>>>
>>>>> Thanks;
>>>>>
>>>>> -jason
>>>>>
>>>>> _______________________________________________
>>>>> Nmc-wg mailing list
>>>>> Nmc-wg at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>>>>
>>>>>
>>>>>
>>>> --
>>>> +--------------------------------------------+
>>>> Slawomir Trzaszczka
>>>>
>>>> Poznan Supercomputing & Networking Center
>>>> +--------------------------------------------+
>>>> <eventTypes.pdf>_______________________________________________
>>>> Nmc-wg mailing list
>>>> Nmc-wg at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>>>
>>>>
>>> _______________________________________________
>>> Nmc-wg mailing list
>>> Nmc-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>>
>>>
>>
>> _______________________________________________
>> Nmc-wg mailing list
>> Nmc-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>
>
More information about the Nmc-wg
mailing list