On Wed, 02 Dec 2009 14:37:09 -0800
Renee Danson Sommerfeld <renee.sommerfeld at sun.com> wrote:
> On Wed, Dec 02, 2009 at 03:32:47PM -0500, Anurag S. Maskey wrote:
> > Michael Hunter wrote:
> > >>You mean you prefer that the walk always be sorted without having to
> > >>specify the flag or changing the order of objects in the files
> > >
> [...]
> > >The third sentence makes the performance argument (which I thought
> > >ya'all would bring up from the beginning). Given the length of this
> > >list and the use of the API I don't think performance is a strong
> > >enough reason to increase the complexity by an order of magnitude.
> > I didn't explicitly say performance, but I did mention that keeping
> > the objects sorted in the .conf files will make writes more
> > complicated. It could require that nvlist be sorted (I don't know
> > the innards of nvlists). That implementation is much more complex
> > than the addition of the flag and the flag also gives consumers
> > freedom in how they want to walk the objects. With the addition of
> > vnics, aggrs, etc in the future, the list could be much longer.
>
> So it seems to me we have three choices:
>
> a) store the objects sorted alphabetically, no flag needed, walks are
> by default sorted alphabetically
That trades more complexity in the backend for simplicity up front.
>
> b) store the objects as-created, but always sort alphabetically when
> walking (except for wlans if priority order is requested); no flag
> needed.
I like the simplicity of this solution.
>
> c) store the objects as-created, no sorting by default, have flag to
> request alphabetic sorting
I don't see a requirement for this.
>
> I think (a) and (c) both add complexity. (b) is probably the simplest,
> but results in unnecessary extra work (the qsort) being done in some
> cases.
>
> I don't have a *strong* preference, but I would lean toward option (b).
> Each of the three options has a down side; the down side of that one
> (doing extra work in some cases) seems the most tolerable to me.
My preference would first be b then a. Option a has a lot going for it
in keeping the complexity in the backend. But b is so simple. Like
<10 lines with comments. c is something like triple that spread all
over the place. And we've already found one bug during code review. I
can't see a being any easier.
>
> > >I havn't read a response from you to Renee about the ordering but I
> > >agree that straight alpha including the type namne isn't exactly what
> > >we want.
> > The type name is not compared, but the type enum. In the enum, the
> > link comes before the interface, so that links are listed before the
> > interfaces. I also included sample outputs in the response to her
> > email.
>
> Yep, and the sample outputs he sent were sorted as I thought they
> should be, so I'm happy with the way that works.
Great!
Michael
>
> -renee
