libmsrpc registry key handle suggestions
cnicholl at uoguelph.ca
Wed Jul 13 16:36:42 GMT 2005
First a short status update:
I started working on how an MsRpcServerHandle would operate, and what
data it would need to contain. But I realized that the definition of it
would evolve as the needs of different funtions are laid out. So i
started working on figuring out what functionality to provide and how it
would work (keeping the server handle in the back of my mind).
I decided to start with the winreg pipe, and a small question has
arisen, that is how to deal with multiple registry key handles (ie if
you open a registry key, and then open a subkey of that key then there
are 2 open registry key handles). At first I wanted to keep as much
data as possible in the MsRpcServerHandle and not force the user to
worry about it. I think a big goal of this library is to be easy to use
for development, but at the same time not confine the user to a limited
set of functionality. So there are a few options that i've come up with:
1. Keep a reference to the latest open key handle in the MsRpcServerHandle
- This will be pretty easy for a developer to work with they simply
pass the server handle into a function and never have to worry
about key handles. But this will limit the functionality becuase they
only have access to one open key handle.
2. Force the developer to manage their own open key handles
- This is probably the most straightforward approach for everyone.
The developer has to worry about the specific key handles,
but they are open to do whatever they like with them.
3. Use some data structure in libmsrpc to worry about all the handles
(maybe a stack?)
- using a stack could work, since only subkeys of an opened key can
be opened, the library can simply make sure that once a
key is closed, the key handle is popped from the stack and the next
handle in the stack (for the parent key) is referenced as the
'current' valid handle
- this may only contribute to the complexity of the library and
might not make it easier/better to work with
I have a feeling that I will end up settling for option 2 as it is
balanced between ease of use and flexibility, but does anyone else have
any suggestions about this?
More information about the samba-technical