Am Dienstag, 6. Februar 2007 03:34 schrieb Avi Alkalay:
> Hi Glenn and Sriram
>
> I understand you are working on a cross-platform product that needs a
> registry. So you picked up Elektra to be the store and are implementing
> Windows-like API to wrap it. Thats great news.
Yeah, even I would more tend to use the windows registry as backend for
elektra. The other way round will lead to the ugly names and types windows
already have, which we can avoid now.
> See below some comments.
>
> On 2/2/07, Glenn Curtis <[EMAIL PROTECTED]> wrote:
> > For your info, we were missing some flags in the create entry code to
> > indicate which nodes are to be treated as a directory type vs. a value
> > type. We were also using the filesys backend, and were having problems
> > due to this missing flag with the root directory not being created
> > properly, and thus most operations following were not working. We also
> > had some usage issues with writing the value data into the file.
>
> I'm not sure if I understand this point. Since last version you can assign
> values to directory keys, just like WinReg. And the root directory
> ("system" or "user") is created as soon as you access the tree with correct
> permissions.
Are you sure with that? I thought user/ will be created after you have created
a subfolder, not by accessing. This really must go into documenation!
> In fact, the main difference between binary types and sting types is
> Unicode handling. So REG_SZ can be KEY_TYPE_STRING, REG_DWORD can be a new
> binary or string type, and REG_MULTI_SZ can be a new string type with a
> separator, or a new binary type (but then you loose automatic Unicode).
Did anyone even check if the unicode convertion conflict on windows? On utf8
systems this functionalty should not be compiled into elektra anyway.
>> The impression I have about Elektra is that there is some momentum
> > missing, and as a result there is a fair amount of holes in the
> > completeness of it. This I determined from the comments on the web about
> > the support of various bindings and backends. It is in need of some
> > evangelizing to get adoption momentum in place. As Jerry pointed out, we
> > are keen to leverage this within our product for storing system settings
> > and Group Policy settings that should be applied to system components.
> > Maybe we will be able to help configure the systems we are installed on
> > with Elektra, and start to seed the system registry with settings to be
> > followed.
>
> Yes, indeed. I made a lot of evangelization, and yes, there are some
> missing points, but I believe Elektra is ready now to be used by C, Shell
> and XML-related programs.
I am working on some missing parts now *g*
But notification is too heavy for now, but its a must-have before 1.0, because
I am afraid it will need some api changes.
>> I was curious why your APIs were not modeled in a way similar to NT, is
> > there a possible IP concern? Or is the flexibility of back-ends and
> > bindings what led to the design?
>
> Elektra API was not modeled as Windows Registry because I never used WinReg
> API. I have no idea how it looks like.
You should look at it. But the core design of elektra as now is really great
(Thank you Avi!). I really love the three classes (key, keyset and kdb
seperation), the backends, xml export importing and so on. I dislike the
typing system (its in someway not optimal) and the not transaction aware
remove, link (I am working on that).
> If there is a goal to centralize all data into a common system store, it
>
> > would seem confusing to allow application writers the choices of
> > backends and where each may store their data. Have there been any
> > thoughts on a backend that models the windows registry hive, which is
> > perhaps loaded in like a memory mapped file?
>
> I totally agree. Backends were invented to satisfy an insistent request
> from the community that wants "choice". In the end, the modifications we
> did to the Elektra source to support backends made it more modular and
> nice. Currently, multiple backends are there to people experiment. Each
> backend has advantages and drawbacks. The filesys, is 100% secure but is a
> storage eater. And berkeleydb is fast, small storage footprint but can't be
> 100% secure, so it needs to be combined with the daemon backend, which is
> already implemented. But as a long term perspective, only one backend will
> exist.
Don't say that. Its impossible to fulfil the needs of a large server network
and an embedded system on flash at once.
>> Would you be interested in having the NT style wrapper interfaces we are
> > writing to include with Elektra SDK?
>
> Of course yes!
> Windows is the only platform that has a Registry API.
No, other are: AIX with its SMIT (it has something like a C-Api for
configuration too), wine, or if you want an os reactos, desktop systems like
kde, gnome (its a platform too..) and many, many applications which contain
more programs using the same configuration like postfix,...
> Elektra was designed
> to be a cross platform API for a registry functionality. So - please
> understand I don't have the complete vision why you started to develop a
> WinReg wrapper to Elektra - in my opinion, the best way would be to develop
> a WinReg backend to Elektra, so WinReg is the storage backend for Elektra.
> This way a crossplat application will use a crossplat API - Elektra - to
> access a registry. On Windows, Elektra will use WinReg. On Linux would be
> filesys or any other. But Elektra guarantees facilities as crossplat XML
> import and export, consistent namespace, etc.
Yeah, I absolutely agree.
thank you
Markus Raab
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Registry-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/registry-list
