Re: New libquran architecture and features

["Mohammad DAMT" <mdamt at gnome dot org>]

Salaam alaykum.

On 7/23/07, nabil ben khalifa <nabil_benkhalifa at yahoo dot fr> wrote:
> Well I think that it is a good beginning but some
> ideas need to be more clear, for example what do you
> mean by binary xml files ?

It's not binary xml files, but XMLs which is converted to binary files.
We use XML in development phase, eg. editing the quran text, etc. In
deployment, we pre-compiled the XML into a binary format. The format
can be in a very simple format and we just add some functions to read
and write to the file.

sqlite is also a good choice. But still we need the XML as the source
data, then in deployment, we read the XML and generate the sqlite db
file. This also means binary files.

The first option is good as it doesn't add a dependency to any library
and it is easy and fast. But the drawback is we can't do some
sophisticated search in the texts (e.g. select * from quran where ayah
like '%heaven%').

The second option is the opposite :-) and sqlite is in public domain.

Which way do you guys want to go? I prefer the second.
Nabil also said to use sqlite, so we have 2 votes already :-)

> Are plugins really needed ? why we don't offer
> compilation options so that everyone can compile
> libquran with the adequate options for his platform ?

This also would work (and also a bit faster because there will be no
additional symbol resolving in runtime). But, we also need to support
multiple formats, and having each plugin to implement some interfaces,
for example:

libquran_plugin_play_audio ();

Then when we want to play an .mp3 we call call
libquran_plugin_play_audio (), if we have speex, we also call
libquran_plugin_play_audio (), if we have .wav we also call
libquran_plugin_play_audio () and let the plugin manager choose which
component does the playing.

And it's quite challenging if it's done without plugins.

Thanks for all comments.