Re: Summer of Code

["Ahmed Ghoneim" <ahmed dot ghoneim at gmail dot com>]

Salam 3alikom Meor,

Thanks. I appreciate the quick and clear response. please bear with
me, as I'll address the points in somehow different order.

Portability:
Absolutely. I've compiled it under win32 using mingw, and created a C#
bindings for it, and a simple C# frontend. I'm fairly confident i
could port it to other platforms, i just think the source tree could
use cleaning/dusting off to make it compile effortlessly anywhere.
Mind you, i didn't port it to win32, i just did some fixing.

Related projects:
i Agree with you, this is why i created the C# bindings (posted here
but there was no interest, will post again when 100% ready) and ISA
will create Java bindings, the way i see it we should have  one
library and many bindings, not multiple portings (sometimes
incomplete). I'm no pearl PHP expert, but i guess it won't be big deal
to create bindings for them.

One File per aya:
Good point, i was wrong, i didn't think about the "fast" muqre2 :)
(e.g. Ahmed Al Ajamy, Mashary Rashed ).
i guess if we have a well documented interface it would be good.

Audio Support in the library:
I'm afraid i'll have to disagree. IMHO this will push most of the work
to the client end, and will make the lib a very thin layer,
effectively transforming it to a mere specification of audio and text
format!
IMHO the lib should be simple yet prvide basic functions. request
text, get text, request tafsir get tafsir text, request translation
get translation text, request audio get plain old raw PCM audio then
play it as you please.
As for the speex/ogg whatnot dependences,  they are pretty small, i
guess we could always static link them, it's not like we need the
cutting edge release.

hope my words made sense (it's late here).

Salam 3alikom, and thaks to all.

Ahmed Ghoneim

P.S.
If you have experience with fonts, i really could use some, as the
quran font does strange things on win32.


On 3/12/07, Meor Ridzuan Meor Yahaya <meor dot ridzuan at gmail dot com> wrote:
> Salam, Ahmed,
> I just assume you are refering to me in your below paragraph. FYI, i
> have not been programming C in a very long time (except for a very
> simple program). I do program in a higher level languages, such as C#,
> Javascript and Perl. With that in mind, here goes. Let me break the
> issues into several topics.
>
> 1. 1 file per ayah
> To me, this is a major barrier if we would like other people to
> contribute to the project (in terms of audio - assuming we are
> expecting people to contribute, otherwise, it would be a different
> story). Even if people will not contribute, it will make them very
> difficult to have their own audio preference. For example, some famous
> qaris (don't have tpo mention name here) are well known to recite
> continously for several verse. This will make it almost impossible to
> support in current libquran design. In my application, i just store
> the following information about the audio (for each ayah): filename,
> start time, end time. For continuus ayah, i just put -1 in the
> start/end time. Then, the application will have to know how to handle
> it. Users can create their own data file for the audio, so they can
> listen to their favourite qaris.
>
> 2. Portability
> I'm curious, is the current library portable enough to be ported to
> platform other than *nix?
>
> 3. Audio support in the Library
> My opinion is, not to have build in support in the library. It should
> be able to handle the data about the audio, as mentioned in no 1.
> Playing the audio will be up to the application. I think this will
> make the library more portable. The application may not be that
> portable, since we need to create application for our target platform
> ie KDE, GNOME, Ms Win* etc. Application can use whatever method easier
> to it (using libspeex/libogg, gstreamer, karts,directx, or even using
> component model like bonobo,kparts or COM - I use media player to play
> the audio). By having something like this, the application can be
> created using higher level languages by glueing multiple technologies
> at the same time. We don't have to wait for libquran to support
> protected wma file format - just ask media player to do it.
>
> So, that is my view on the library. It should be simple and portable,
> then more people will be using it. I think because the library itself
> is tied to certain technologies, it forces application developer to
> rewrite the library. You can look at the related project; jquran and
> c#. Both application does not use the library at all; they just use
> the data files. As for me, right now my application does not use
> anything from the project, even though I try my best to make it
> compatible to it.
>
> Regards.
>
>
> On 3/13/07, Ahmed Ghoneim <ahmed dot ghoneim at gmail dot com> wrote:
> > S3,
> >
> > > > >> We could do in more lower level than the current libquran. Let it just
> > > > >> return the audio data along with it's mime type (it could be mp3,
> > > > >> speex, or anything). The playing of the audio is the responsibility of
> > > > >> the frontend, not libquran's.
> > IMHO the current approach is better, playing/rendering the audio is of
> > course the responsibility of the frontend , but the library should
> > provide a standard interface and be consistent with regards to the
> > type of data it returns. right now the PCM buffer is excellent, any
> > kind of frontend should be able to hanlde it, plus it lowers the
> > barrier to entry for new frontends (read easier to develop). And most
> > importantly, we could always change the encoding/format of data
> > without requiring *huge* changes to the clients, merely a recompile
> > against the new lib.
> > This is an area that i think don't any fragmentation. One Text, One
> > Audio format.
> >
> > > > >> In this way, people could use libquran also when they don't need the
> > > > >> audio data. Today they should have libspeex in order to compile.
> > > > >>
> > > > >
> > > > >Nice idea, so that we needn't force an install of the audio data.
> > Right now the *don't* need the audio data to run, you could run it
> > just fine without it. You do need the libspeex plus libogg though, but
> > thats a no biggie, it's almost standard on *nix and it's only a couple
> > of dll on win32
> >
> > > > Last time, i suggested something like this to M Yousif. It would be
> > > > better to be more flexible. I suggested to use something like
> > > > gstreamer or karts for audio handling, so that we don't have to worry
> > > > about supporting every audio type exist. That would be gstreamer's
> > > > job. Another thing that is not flexible in current audio handling is
> > > > the requirement of 1 file per ayah. the approach that I took for my
> > > > web application was we only store certain information about the audio.
> > > > Info that we need (in the library) are for every ayah, where is the
> > > > audio file, it's start time and it's end time. Then it is up to the
> > > > application to play it. I've uploaded the application, but I need to
> > > > fixe a few things before announcing it.
> > >
> > > I don't know why M Yousif didn't like the idea bit IMHO, gstreamer will increase the dependencies
> > > of libquran which something I personally don't like.
> > I concur, gstreamer would me make life very difficult for people
> > porting libquran to win32 i.e. me. please give some thought to the
> > cross-platform-ness of this. while gstreamer is almost native to *nix
> > and gnome, it's a pain in the neck to run under win32, and no cygwin
> > is out of the question, when i say win32 i mean *native* win32, that
> > is Mingw, right now the current scheme speex/ogg works perfect under
> > win32 with Mingw
> >
> > > I guess your approach in handling the audio files seems better.
> > again, if the current scheme stays, the libquran passes PCM buffer, so
> > the frontend does not know/care if it's from a single file or from a
> > position within a larger one.
> > but i would guess it would make creating audio sets harder for
> > volunteers, but then again i don't have much experience creating them.
> > could you please provide more info on your solution?
> >
> > Thanks to all,
> >
> > Ahmed Ghoneim
> >
> > _______________________________________________
> > Developer mailing list
> > Developer at arabeyes dot org
> > http://lists.arabeyes.org/mailman/listinfo/developer
> >
>
> _______________________________________________
> Developer mailing list
> Developer at arabeyes dot org
> http://lists.arabeyes.org/mailman/listinfo/developer