Re: Mixing dbconfig and gconf
On Mon, 2008-06-30 at 15:39 +0200, Loïc Minier wrote:
> On Mon, Jun 30, 2008, Neil Williams wrote:
> > Is this a sane use of dbconfig and gconf?
>
> I might misunderstand what you're doing, but I think you're setting up
> GConf default systme-wide.
Only for certain settings related to installed package selection. Much
like the system user for MySQL and PostgreSQL installations - in effect,
it is used to tell the IDE which backends are installed and the
configuration for each. Rather than ask the admin every time a new
backend is installed, each backend can use the one dbconfig config.
The IDE can then offer those amongst other userspace backend
configurations.
Think of it a bit like the reserved tables set up by MySQL and
PostgreSQL - the dbconfig data creates tables for estron-gnome that are
roughly equivalent to the internal tables used by the DBRM itself. The
applications written using the IDE then use their own tables, much as
any package would when using MySQL or PostgreSQL directly.
> Usage of GConf for system wide
> configuration (of default databases) is a bit weird, but it's valid, as
> long as you only set system wide things such as system gconf defaults
> or system gconf mandatory settings. Perhaps one way to do this is to
> seed a /usr/share/gconf/defaults/foo file and run update-gconf-defaults
> after that.
My problem is that the first time the IDE runs, it will need to have
this data available - hence the alternative of a Gtk wizard.
> I wouldn't recommend running gconftool-2 directly though,
> unless you would do so in a very controlled location of the gconf path
> which /etc instead really.
I don't follow - currently, the schema goes into:
/usr/share/gconf/schemas/estron-gnome.schemas
What do you mean about a gconf path from /etc ?
> > Do I really need to write a Gtk wizard instead?
>
> I don't think db configuration needs to happen system wide; I'd rather
> expect each user to have per project database settings so it would seem
> to me it's that a real UI to configure such stuff per-user and
> per-project would be useful anyway.
Multi-level - each "project" defines the datasource configuration and
can use any of the available methods. The gconf data only relates to how
the IDE offers optional backends. Each backend is a bit like a plugin
but each can have installation-specific config.
Once the application is developed within the IDE, it can be reconfigured
for another backend or another configuration, allowing site-specific
configuration.
e.g. an app written using PostgreSQL on one machine can be reconfigured
to work with a SQLite backend on a slower machine (and can support data
export -> import across backends too).
At each stage, the application config is separate from the system-wide
IDE config going into gconf.
> > I'd still like to use dbconfig, so I would still end up using both
> > dbconfig (in Debian) and gconf (upstream) *as well as the wizard* which
> > would have to know how to get Debian-specific config data instead of
> > asking the user again so it would need to support some kind of
> > command-line configuration option to say "got config already in file
> > blah". Seems like a lot of work to me.
> >
> > I get the impression dbconfig is geared more towards Web2.0 type stuff
> > rather than compiled programs.
>
> Not quite sure why you target using dbconfig; I had the impression it
> was mostly aimed at setting up packages, not for per-user data.
But that is how I'm using it - dbconfig is used to set up the IDE
package on a system-wide basis.
The IDE then allows the development of other applications that can
choose from a variety of data connections, including some that are
system-wide, some that are userspace and some that are remote. The
applications can have a *different* system-wide config to the IDE
because these can be packaged as individual packages themselves, just
depending on the interpreter.
estron-gnome: IDE
Offers a selection of estron backends, some of which need
configuration. Any backend can be installed as long as there is at least
one. It is this stage that needs the dbconfig/gconf config so that the
IDE can offer the backend to any project being developed - including the
ability to create a separate config for each project, hence the need for
a super-user, system-wide, config that has CREATE privileges.
estron: interpreter
Runs the IDE (which itself is written in estron) and all estron
applications. It is the only dependency needed by stand-alone estron
applications.
backends: sys-admin able to select whichever backend is most suitable
for that box. Available to the interpreter and thence to the IDE.
There is no user-specific config, as such. There is project-specific
config, this is then carried over into the standalone application,
embedded within the estron file itself. Someone else with the IDE can
then tweak the application and use a different data source. Some
applications will use personal passwords, some can be prepared as Debian
packages and have their own system-wide config.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Reply to: