GSoC - ncurses registry editor

[C Davis]

Hey. Thanks for your response, Michael.


On Thu, Mar 29, 2012 at 9:01 AM, Michael Adam <obnox at samba.org> wrote:

> Hi C,
>
> C. Davis wrote:
> > Hello,
> >
> > I'm interested in applying for the ncurses registry editor project for
> > GSoC.
> >
> > Should the user interface resemble Windows' regedit to allow users to
> > fully enumerate/edit the registry on a remote Windows system, or should
> it
> > be more geared towards just configuring Samba (by providing an interface
> > for managing shares, etc)?
>
> It is meant as a general purpose editor for registry.
>
>
Ok. I was thinking of mimicking regedit's interface, as it's pretty
simple and familiar. There would be a tree view for keys on the left,
and a panel for viewing/editing values on the right. A tree view similar
to the file system navigator in "Midnight Commander", another ncurses
project, would work pretty well for navigating the hierarchy of keys in
the registry, and it shouldn't be too difficult to implement.

> >From tracing how "net registry" and "net rpc registry" work, it appears
> > all the code for accessing the registry locally and remotely already
> > exists (code in registry/ for local access, and rpc_client/ for winreg
> > RPC). I assume not much (if anything) would have to be done here for the
> > ncurses editor.
>
> Right. We have "net [rpc] registry" as a command line tool
> for reading and writing the registry (locally for samba
> and remotely via RPC on a server that supports the winreg
> RPC protocol, like windows and samba).
>
> The basic idea is to have a full featured curses based registry
> editor to use instead of these tools for a much less clumsy user
> experience.
>
> > The project hint on the Wiki page mentions using "plugins" for registry
> > backends, which makes me think of something like browser plugins that are
> > dlopen'd on the fly. Would something like that really be required for
> this
> > project, or am I confusing what was meant?
>
> Well I think of different "backends". One backend would be the
> local samba db access used by "net registry" (called reg_api).
> Another backend would be samba3's winreg RPC api to access a
> remote server. It is thinkable to add more backends. (like the
> registry implementation of samba4 (source4/) that is still
> separat from samba3's implementation at this very moment.
> Or some completely different backend / api.
>
> Whether these are to be linked in or loaded at runtime, is not
> completely clear yet. This is still to be discussed and also
> partly subject to the implementer's phantasy... :-)
>
> Cheers - Michael
>
>
>
Hmm. It seems the biggest benefit of having a true plugin
system with backend modules loaded at runtime would be
to offer users a means to add custom modules without
being forced to recompile Samba. If users are unlikely to
do that, then it'd be simpler to just link in, IMO. Though, I
think the API for backends should be largely the same
regardless of whether or not dynamic loading is supported.
With Python modules/types written in C, for example, the
"built-in" stuff uses the same API that extension modules
do.

Is there anything else to go over? I'd like to send in a gsoc
application before the deadline.

Thanks.