libmsrpc registry key handle suggestions

[Chris Nicholls]

Hi,

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?

Chris