[Nmc-wg] Base doc

[Nina Jeliazkova]

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). 

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/ac9ffca0/attachment.html