[Scribus] Re: Ideas on collaboration

[Craig Ringer]

On Sat, 2005-06-25 at 15:51 -0700, Asif Lodhi wrote:

> Further, I worked with Oracle 9i database about a year ago and the
> database server had the functionality to hold a particular (most
> heavily used) part of the database completely in the memory (I am
> talking about the in-memory database).

That's pretty typical, though I expect Oracle offers the admin more
control over it than most do.

> Though I haven't used SVN yet
> but I do know that its data store is based on "Berkley DB" which is
> also being used by MySQL now which (MySQL, that is) also supports
> in-memory databases.

Regarding bdb: *hiss* *spit* . There is no other piece of software that
has caused me more problems and data loss as a sysadmin. Recent versions
can be very reliable if built with transaction support and if the apps
use that transaction support, but some distros even now build BDB
without transaction support. BDB is also very vulnerable to issues
caused by even small corruptions due to disk issues, hard poweroffs in
the middle of a write, etc.

BDB can work great, but it's really hard to get right. The 700 page book
on the shelf behind me - the Berkley DB manual - reinforces that
view ;-)

I think Berkley DB is a fantastic tool for keeping a working store of
data, so long as you keep the data in another format (presumably one
harder to edit on the fly, etc) somewhere else.

SQLite seems to be showing up more and more as a potential alternative
to BDB, and I find it more attractive myself. One advantage of using
SQLite is that if you need "bigger" DB functionality later, or need to
hook into a db like oracle or PostgreSQL with proper concurrent
transaction support etc, you can do so much more easily.

I do think that however it's done, putting the Scribus file into a
database and using the database's concurrency and locking features would
be an interesting way to do multiple-user editing. A *huge* amount of
work, I think, but potentially saner than most of the other approaches I
can think of. Whether each copy of Scribus would talk to the db direct,
or whether they'd use a "scribus document server" that knew all the db
specific bits, I don't know.

The whole document-in-database thing isn't a new discussion. Like most
of the things discussed here, what we really need is someone to say "I
have the time and skills, or the time and am willing to learn the
skills, to do this. Where do I start?" These folks, alas, do not grow on
trees.

> So, don't you think Subversion's "Berkley DB"
> data store could be modified/configured to hold everything (DTP/.sla
> files, that is) in-memory to keep the disk-contention to the minimum?

Berkley DB is from SleepyCat software. It's only relationship with svn
is that svn uses bdb. The more recent versions offer the option of a
flat file store as an alternative because so many people just wouldn't
trust bdb (myself included), too.

If a doc-in-database scheme was implemented, I suspect it'd be better
done with a "scribus doc server" to mediate requests and hide database
implementation specific details. With that, the database back end could
even be made configurable, and bdb would be one option to investigate,
yes.

--
Craig Ringer