[Nmc-wg] Base doc
Nina Jeliazkova
nina at acad.bg
Thu Jan 14 09:52:47 CST 2010
Nina Jeliazkova wrote:
> 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.
>
>
Just out of curiosity - was it considered before to make use of SOAP
fault codes [
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383492 ], instead
of custom solution?
(I can easily see one advantage of a custom solution, since error codes
can now be associated with data/metadata entries ).
Nina
> 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
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nmc-wg/attachments/20100114/59902b71/attachment-0001.html
More information about the Nmc-wg
mailing list