You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Oliver-Rainer Wittmann <or...@googlemail.com> on 2011/12/05 13:32:16 UTC
[code] usage of Berkeley DB
Hi,
here is the status of my findings regarding the usage of the Berkeley DB:
It is used in modules l10ntools, xmlhelp and desktop.
In module l10ntools it is used by 'dead code' in a tool called 'HelpLinker'. The
'HelpLinker' tool is used in module helpcontent2 to prepare the help content
data for the help system. As this is 'dead code' I have already removed it in my
local environment. I have checked the resulting installation and the help system
still works.
In module xmlhelp it is used for the help system to _read_ Berkeley DB files. As
far as I have figured out the Berkeley DB files which may be accessed are the
ones which may have been created by the preparing the help content data.
As such Berkeley DB files are no longer created - see above - I am currently
removing the code accessing Berkeley DB files in module xmlhelp in my local
environment. I will follow-up on this here, when I have checked the resulting
installation.
In module desktop it is used for the management of installed extensions. For
each installed extension a key-value-pair is stored in a Berkeley DB file. There
are created certain Berkeley DB files in an installation for various purposes.
The intrinsic data type of the 'key' and the 'value' is <string>.
Thus, it looks like that we only have one 'real' dependence on Berkeley DB - the
management of extensions.
feedback/comments/support is welcome.
Best regards, Oliver.
Re: [code] usage of Berkeley DB
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 05.12.2011 13:32, Oliver-Rainer Wittmann wrote:
> Hi,
>
> here is the status of my findings regarding the usage of the Berkeley DB:
>
> It is used in modules l10ntools, xmlhelp and desktop.
>
> In module l10ntools it is used by 'dead code' in a tool called 'HelpLinker'. The
> 'HelpLinker' tool is used in module helpcontent2 to prepare the help content
> data for the help system. As this is 'dead code' I have already removed it in my
> local environment. I have checked the resulting installation and the help system
> still works.
>
> In module xmlhelp it is used for the help system to _read_ Berkeley DB files. As
> far as I have figured out the Berkeley DB files which may be accessed are the
> ones which may have been created by the preparing the help content data.
> As such Berkeley DB files are no longer created - see above - I am currently
> removing the code accessing Berkeley DB files in module xmlhelp in my local
> environment. I will follow-up on this here, when I have checked the resulting
> installation.
I have checked the resulting installation of my local environment having removed
the Berkeley DB usage code from xmlhelp.
The help system works - at least my test cases. Also, the help content of a new
installed extension is working in the help system.
>
> In module desktop it is used for the management of installed extensions. For
> each installed extension a key-value-pair is stored in a Berkeley DB file. There
> are created certain Berkeley DB files in an installation for various purposes.
> The intrinsic data type of the 'key' and the 'value' is <string>.
>
> Thus, it looks like that we only have one 'real' dependence on Berkeley DB - the
> management of extensions.
>
> feedback/comments/support is welcome.
>
>
Best regards, Oliver.
Re: [code] usage of Berkeley DB
Posted by Herbert Duerr <hd...@apache.org>.
>> Using a database system to manage a handful of extensions sounds like "using
>> a sledge-hammer to crack a nut" and a rather tiny nut at that.
>>
>> I'm looking into replacing it with something much simpler.
>
> How about a file called extensions.properties or extensions.ini or
> something like that. If these are really just string name/value
> pairs, and we're dealing with, say, 1000 or fewer of them, then a
> linear search of then should be fine.
Yup, that's plenty sufficient. For the in-memory structure I prefer an
map (unordered or ordered) though because it scales much better.
> Also, do we know, are these UTF-8 strings, UTF-16, or just ASCII?
Neither: it is a concatenation of UTF-8 strings and values separated by
an invalid UTF8 char. For details please see the code comments starting
with "Old format" or "New format" in the source file
main/desktop/source/deployment/manager/dp_activepackages.cxx
Herbert
Re: [code] usage of Berkeley DB
Posted by Rob Weir <ro...@apache.org>.
On Mon, Dec 5, 2011 at 10:04 AM, Herbert Duerr <hd...@alice.de> wrote:
>> In module desktop it is used for the management of installed extensions.
>> For each installed extension a key-value-pair is stored in a Berkeley DB
>> file. There are created certain Berkeley DB files in an installation for
>> various purposes. The intrinsic data type of the 'key' and the 'value'
>> is <string>.
>>
>> Thus, it looks like that we only have one 'real' dependence on Berkeley
>> DB - the management of extensions.
>
>
> Using a database system to manage a handful of extensions sounds like "using
> a sledge-hammer to crack a nut" and a rather tiny nut at that.
>
> I'm looking into replacing it with something much simpler.
>
How about a file called extensions.properties or extensions.ini or
something like that. If these are really just string name/value
pairs, and we're dealing with, say, 1000 or fewer of them, then a
linear search of then should be fine.
Also, do we know, are these UTF-8 strings, UTF-16, or just ASCII?
-Rob
> Herbert
Re: [code] usage of Berkeley DB
Posted by Herbert Duerr <hd...@alice.de>.
> In module desktop it is used for the management of installed extensions.
> For each installed extension a key-value-pair is stored in a Berkeley DB
> file. There are created certain Berkeley DB files in an installation for
> various purposes. The intrinsic data type of the 'key' and the 'value'
> is <string>.
>
> Thus, it looks like that we only have one 'real' dependence on Berkeley
> DB - the management of extensions.
Using a database system to manage a handful of extensions sounds like
"using a sledge-hammer to crack a nut" and a rather tiny nut at that.
I'm looking into replacing it with something much simpler.
Herbert