Design and feature suggestions

[Ethan Blanton]

Christian Wisner-Carlson spake unto us the following wisdom:
> *Split Pidgin and Finch from libpurple completely, so that the backend
> and frontend may run on different machines, allowing multiple frontends.
> This would allow people to put libpurple on their servers, leave their
> accounts always signed on, and be able to roam between their computers
> seamlessly. 

This has been under discussion for as many years as I have been
involved with the project.  The only reason it has not yet happened is
that it is a Big Task.

The advent of finch (which can be run in screen) has mitigated the
pressing need for this significantly, but it would still be a welcome
development.

> *MySQL/SQLite integration: The pidgin buddylist format is slow,
> disorganized, and easily corruptible (I have to delete it and rename my
> contacts every once in awhile). Allowing libpurple to store buddy
> information, account information (encrypted hopefully), logs,
> configuration, etc in a database would make it much easier to add
> features as well, eliminating the need for specific file access. Plugins
> could also store information in the database. This would also provide an
> incentive for enterprise use, when combined with the previous
> suggestion. 

This, I do not understand.  What makes you say the buddy list format
is slow?  Are you aware of a situation where it matters, or is that
just hypothetical?  Why is it disorganized?  It is, in fact, a
structured tree -- which is just as organized as relational tables,
and more directly suited to our usage.  Furthermore, if you are seeing
corruption, please document and report it as bugs.  Using a database
engine will not fix this problem, as we would undoubtedly simply
insert corrupted data into the database, for the same reason we are
inserting corrupted data into our configuration files.

As to making it easier to add features, we already have an abstracted
preferences interface, such that those who wish to add features need
not care how our preferences are stored.  Plugins can already store
information in our preference files, and many do.

It sounds to me like you've been caught up in a buzzword, and view a
"database" as some sort of magic bullet which it is not.  There is no
practical upside to storing our configuration in a database, rather
than XML files.  Any benefits which are realizable under a database
storage backend are realizable under other backends, with greater or
lesser amounts of effort.  Database backends are a clear win when one
has to consider massive concurrency, transactions, etc. -- things
which are not relevant to IM program preferences.

> I've had many other ideas that I cannot recall at the moment. I'll try
> to send them when I do. Please provide me feedback on these ideas if you
> have the time.

Thank you for your input.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080309/098abbb3/attachment.sig>