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.
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.
Please provide more info.
We are now in a happy place with the exception of one bug which is a
by-product of the filesys backend. We cannot create a Key node with name
"Foo" (handled as a directory folder on the file system) and a peer
Value node (handled as a file on the file system) with the same name. To
mitigate this, we are going to decorate all value node names with some
extension so that there is no name collision. As we are writing an NT
style Registry API equivalent wrapper over the Elektra APIs, our
implementation will make the name decoration under the covers.
Directories can have values now. Will this solve this issue ?
We are also going to support all the NT style registry value types
(REG_DWORD, REG_MULTI_SZ, REG_SZ, ...), since Elektra only support
binary and string formats, we will store our data in a serialize format
to add a type/length field in front of the raw data, and store it as
binary.
Binary and string are Elektra's generic supertypes. You can actually define
your custom types without having to pack your values with more info into the
Elektra's value. Check documentation on
http://www.libelektra.org/elektra-api/group__keyvalue.html#ga10 to see how
to define custom types. This was taken from the KeyType doxy documentation:
Key type values grow from the semantically poor to the semantically rich.
The gaps between them is for user-defined types.
If your application needs value types with more semantics, like Color,
Font, etc, you can still use it. You'll have to define a new type number
in the scope of your application, and force the type with
keySetType()<file:///home/aviram/src/elektra/doc/elektra-api/html/group__keyvalue.html#g520575bbb20e6476cbcb9d8a74540032>,
or
keyNew()<file:///home/aviram/src/elektra/doc/elektra-api/html/group__keybase.html#gf6893c038b3ebee90c73a9ea8356bebf>
.
The type number is a value between 0 and 255. If your user-defined type >=
KEY_TYPE_STRING, it will be still treated as a string (in the terms of
Unicode handling). If KEY_TYPE_BINARY <= type < KEY_TYPE_STRING, Elektra
will handle it as a binary value, will not make Unicode handling and will
save it hex-encoded.
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).
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 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.
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.
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. 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.
I think the reimplementation of the WinReg API will suffer the same IP
issues as Wine. But is certainly something some developers may feel useful,
specially when porting Win apps to other plats.
Please by now use version from SVN repo (
http://www.germane-software.com/projects/elektra/browser/trunk) until
0.6.8is not released. The repo has a more complete support for values
on dirs and
a few documentation updates, when compared to the last SF.net version.
Regards,
Avi
--
http://avi.alkalay.net/blog
-------------------------------------------------------------------------
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
