"REGISTRY" back-end for profile info

[Joseph Calzaretta]

At 02:35 PM 11/22/2005, Jeffrey Altman wrote:
> > I hope that means capaths/RAEBURN.ORG should be a key with seven
> > REG_MULTI_SZ values under it:
>
>Unfortunately not.  It is the ordering of the "keys" that is what is
>lost with the existing profile library that needs to be fixed.
>The left hand side values in the case of [capaths] should not be
>considered top-level.   They are order specific and therefore should
>be stored as a whole in a REG_MULTI_SZ.

Ugh, oh well.  So, maybe to preserve ordering we can mangle the key/value 
names to something like
001_ATHENA.MIT.EDU
002_ANDREW.CMU.EDU
...
so that the ordering is automatically preserved.  It's not pretty, but I 
think it's less ugly than storing an entire ordered subtree as a single 
REG_MULTI_SZ turd with internal markers for groupings.

>The current profile library does not have enough type data from the 
>application to be able to do what it should be doing.
>>It seems like there would need to be some additional type information 
>>available to the profile library indicating how the data should be treated.
>
>I selected those three cases because those cases represent the three 
>different models of how the data is treated by the application.
>(1) ordered list of pairs stored as block of lhs = rhs entries
>(2) ordered list stored as a single right-hand-side
>(3) unordered list stored as multiple entries with the same lhs within a block

I was envisioning that the future krb5.conf parser would treat the entire 
tree as ordered (although not sure if it should be treated as 
merged/unmerged... this is yet another discussion).   This would 
automatically fix [capaths].  The API could (if this is desired) give the 
option of retrieving lists in their original order or in lexically sorted 
order.  And I was also not envisioning treating spaced in rhs entries as 
being multiple entries, because if you wanted multiple entries you could 
get them ordered for free like "foo = bar \n foo = baz".  As opposed to 
"foo = bar baz", which would require yet another flag for treating internal 
whitespace as an ordered list separator.

Your three cases would be handled:
(1) automatically: "foo = bar \n baz = quux"
(2) not automatically, but you could store them as multiple lines with the 
same lhs and get this: "foo = bar \n foo = baz", interpreted as "foo" => 
<bar, baz>
(3) if the calling application ignores the returned order of the entries: 
"foo = bar \n foo = baz" interpreted as "foo" => {bar, baz}

>Currently, the profile library fails because it does not understand how 
>the application intends to use the data that it stores.  In fact, I would 
>argue that the profile library as it currently exists is too low-level for 
>its own good.
>
>Instead I propose that instead of the application handling the management 
>of ordered vs unordered lists vs single entries, that the library do 
>so.  Instead the application should indicate it wants to obtain the 
>contents of the ordered list of pairs located at "[capaths] RAEBURN.ORG" 
>and the library would then know how to manage that data.

I'm hoping whatever changes we make can be made to work in krb5.conf format 
too.  So that there is nothing you can do with krb5.conf that you can't do 
in the registry and vice versa, and that the API keeps that in a nice big 
black box for the user.  Otherwise I anticipate many headaches.  It sounds 
like you're suggesting expanding the format to indicate that the data to 
come is ordered or unordered.  For example (but not a serious proposal) 
using angle brackets to mean "ordered list":

capaths = {
    RAEBURN.ORG = <
         ATHENA.MIT.EDU = .
         ANDREW.CMU.EDU = DEMENTIA.ORG
         DEMENTIA.ORG = ATHENA.MIT.EDU
         GRAND.CENTRAL.ORG = <
               ATHENA.MIT.EDU
               DEMENTIA.ORG
               >
         OPENAFS.ORG = <
               ATHENA.MIT.EDU
               DEMENTIA.ORG
               >
         SECURE-ENDPOINTS.COM = <
               ATHENA.MIT.EDU
               DEMENTIA.ORG
               >
         WINDOWS.SECURE-ENDPOINTS.COM = <
               ATHENA.MIT.EDU
               DEMENTIA.ORG
               SECURE-ENDPOINTS.COM
               >
    >
}

But if we're not going to do something like this with krb5.conf, what 
should we do to achieve portability?

>The current krb5.conf loses because it has no idea what context must be 
>applied to the [capaths] section since it can't distinguish between the 
>meanings of [capaths] vs [libdefaults].  They are simply tokens to the library.

I thought it loses because:
   it lexically sorts the tree except for the leaf nodes (much like the 
Windows registry), essentially treating everything as an unordered list.
   you can accidentally hide data (e.g. "foo = { \n bar = baz \n } \n foo = 
{ \n quux = quuux \n } \n", foo/quux is completely inaccessible)

If we change it so that it treats everything as an ordered list, then it no 
longer loses in this way.  But it does push the responsibility of ignoring 
the ordering onto the application, which it sounds like you object 
to.  Thoughts?

--Joe

P.S.  This may not make it to krbdev at mit.edu.  Most of my messages haven't 
been making it.  Don't know why.  :(