<br><br><div class="gmail_quote">On 9 August 2012 20:16, Dan Wendlandt <span dir="ltr"><<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Thu, Aug 9, 2012 at 11:04 AM, Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@nttmcl.com" target="_blank">nachi@nttmcl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Folks, Yong<br>
<br>
In previous netstack IRC meeting, we agreed to use null to specify None.<br>
However you have a new idea for that spec.<br>
<br>
======<br>
My opinion is: On the server side, we treat empty string and None<br>
itself as None. So that We don't need to modify our cli command since<br>
we can use --gateway_ip= to pass in empty string to server. and Other<br>
application can pass in None itself in Json too.<br>
======<br>
<a href="https://review.openstack.org/#/c/10749/" target="_blank">https://review.openstack.org/#/c/10749/</a><br>
<br>
So now there are two spec alternatives.<br>
(Spec1) null<br>
(Spec2) null or ""<br>
<br>
Honestly, I don't case ether of that if all API will follow one spec<br>
consistently.<br>
So let's decide the spec in this thread.<br></blockquote><div><br></div></div><div>I'd rather be explicit and have the API use only JSON null, rather than modify our API design to make writing the CLI easier. </div>
</div></blockquote><div><br></div><div>Agree</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> Otherwise, "" means different things depending on the parameter (since its value to send in "" to mean the empty string for fields like name). </div>
</div></blockquote><div><br></div><div>I'd say that the empty string is the most dangerous of the magic strings, so I would prefer to avoid it, if possible.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div><br></div><div>What about having a CLI flag convention for passing in a None value where it is allowed? Like --no_gateway_ip , which would result in gateway_ip being set to null?</div></div></blockquote><div><br></div>
<div>Totally agree. In general, for each nullable attribute in the API we could have a keyword CLI parameter named --no_<attribute_name> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><br></div><div>Dan</div><div><div class="h5"><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2012/8/6 Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>>:<br>
<div><div>> Hi,<br>
><br>
> To add some more context, we actually have a situation in which by default<br>
> the attribute Nachi is referring to (gateway_ip) is auto-generated, and we<br>
> are looking for a solution to tell the API that the gateway IP should not be<br>
> generated at all.<br>
> It could be argued that the right solution would probably be looking at the<br>
> problem in a different way (e.g.: have "no gateway" as default behaviour)<br>
><br>
> However, for the specific issues Nachi raised, I have been unable to find so<br>
> far similar cases in other Openstack projects. If this is confirmed,<br>
> whatever is decided here might set a precedent, so it is worth dealing with<br>
> this problem in an appropriate way. This might also be important for<br>
> "update" scenarios in which we want to delete (or nullify) the value for a<br>
> specific attribute, as most OS APIs use patch semantics for PUT operations.<br>
><br>
> My personal opinion is that I would avoid using values which are tantamount<br>
> to 'magic values', such as the empty string. the string 'none', also is a<br>
> magic value, although I have to admit it might be acceptable. My preferred<br>
> choice at the moment is having:<br>
><br>
> "resource" : {<br>
> "nullable-attribute" : null<br>
> }<br>
><br>
> for JSON, and something like the following:<br>
><br>
> <resource><br>
> <nullable-attribute/><br>
> </resource><br>
><br>
> for XML. I am not sure however whether this will work well with the current<br>
> deserializers we have.<br>
><br>
> Assuming we will deal properly with patch semantics and nullable attributes<br>
> in Grizzly, it also important IMHO that whatever choice we make here must<br>
> not cause a backward incompatible API change in Grizzly.<br>
><br>
> Thanks,<br>
> Salvatore<br>
><br>
><br>
> On 6 August 2012 20:14, Nachi Ueno <<a href="mailto:nachi@nttmcl.com" target="_blank">nachi@nttmcl.com</a>> wrote:<br>
>><br>
>> Hi folks<br>
>><br>
>> In quantum, we can specify None as a parameter value ( In this case<br>
>> None is not default value ).<br>
>> How we design this spec?<br>
>><br>
>> Design1: "None" ( String) is only allowed with case sensitive.<br>
>> Design2: null ( Json type ) ( This can't support XML )<br>
>> Design3: Allow multiple way. ( None none null "" (empty string) )<br>
>><br>
>> I wanna choose consistent way in OpenStack projects.<br>
>><br>
>> # I think a PTL for API spec is do needed to maintain consistency<br>
>> between project...<br>
>><br>
>> Nachi : NTT MCL<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>