[Nmc-wg] Base doc
Nina Jeliazkova
nina at acad.bg
Thu Jan 14 09:35:19 CST 2010
Roman Lapacz wrote:
> 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'.
Well, also a valid point of view. More important is indeed how much
information can be extracted from the error codes.
Regards,
Nina
>
> 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