Re: Islamic implementation query

[Ali Abdin <aliabdin aucegypt edu>]

* Dirk-Jan C. Binnema (bulkmail dds nl) wrote at 21:04 on 02/12/00:
> Hi Ali,
> 
> Op Sat Dec 02, 2000 at 02:28:36PM -0200 schreef Ali Abdin:
> -> * Dirk-Jan C. Binnema (bulkmail dds nl) wrote at 14:06 on 02/12/00:
> 
> -> > I doubt whether glib is a suitable place for the Islamic calendar
> -> > stuff. IMHO, it's far too non-general. I think you (or someone else)
> -> > even said the calendar isn't used so much in daily life, but is
> -> > mainly for religious purposes. This is not to say that some library to
> -> > calculate Islamic dates isn't useful to some people - it's just that I
> -> > don't think it belongs in glib, just like function for calculating
> -> > Eastern dates, the times of (sun|moon|...)rise and set etc. shouldn't
> -> > be in. So why don't you make a separate library? 
> ->
> -> Because I think the place for it is in glib. glib already has general purpose
> -> functions for Gregorian/Julian date manipulations. It makes sense for it to
> -> have the same support for other calendars that are already in-use out there.
> 
> <snip>
> 
> -> I think it is reasonable to have date manipulation functions for Gregorian,
> -> Julian, ISO, Hebrew, Islamic. These are the only "mainstream" date stuff used
> -> today. I would agree that implementing something like an old Mayan calendar
> -> would be "far too non-general".
> -> 
> -> And please note, just because you don't find it useful, it does not mean
> -> others out there will not find it useful. If you don't find it useful you can
> -> just ignore it.
> -> 
> -> Regards,
> -> Ali
> 
> I'm sure the Islamic date functions are important to some people; but
> there are many function important to some people, and still these
> aren't (and shouldn't be) in Glib. For example (as I said before), 
> functions for the calculation of the Eastern date are in a similar
> position. 
> 
> Glib is a library for general-purpose C-functions. As you've said
> yourself, the Islamic date system is not even the system people use
> normally. I hope you agree that it's important to be very discriminate
> about what goes in and what is not, and the gregorian stuff *is* general
> purpose, while Islamic dates are not, IMHO.

Well, I am basically advocating for Islamic dates (and Hebrew) to be
general-purpose C functions. 

While the Islamic calendar may not be the one used by everyday people in the
street, it is the Official calendar for many Gulf countries (meaning the
government uses it, and hence others need to use it). The /good/ thing about
what I want though is to have a general Gregorian <-> Islamic bridge so the
average person can benefit from it.

I agree that we should be descriminate in what goes in and what doesn't. But I
think the Islamic Date functions are part of what should go in.

You know, you could argue that libc already has Gregorian date functions and
there is no need to include them in glib. And since there are no Islamic date
functions in libc, then they should be included in glib. But I don't agree
with this argument - I think both should be in glib.
 
> I don't want to discourage your efforts to make a nice free software
> implementation of these function; please do so. You could even add
> stuff like the Easterndate -- make a nice libreldate or something. I'm
> sure that programs that would use these functions wouldn't mind the
> extra dependency, and it could even be optional. One could also argue
> that it would be better for these functions to be in a separate
> library, so non-gtk/gnome applications are more likely to use them.

I don't have the resources (FTP/Web/CVS/etc.) to build my own library. I also
do not have the time to maintain an independent library (it takes less time to
maintain two glib files than a whole library (also less headaches)). 

Your argument for non-gtk/gnome apps is not really relevant since I already
depend on glib ;) (i.e. I want a GDate <-> GIslamicDate and I use gint, etc.)
- All you would need is the very leightweight glib library to use, you don't
  need gtk or gnome.

Also having it in glib would be an excellent thing, because you can then use
that as a basis for other things (such as GtkIslamicCalendar!!). You could
also use it ubiquotusly (sp?) in GNOME (i.e. if your locale is set to Arabic
it would show you the Islamic Date!) - Having this as an outside library will
not allow you to do this. I doubt the maintainers of
gnome-libs/gnome-core/whatever would be willing to depend on a libreldate or
something.

At one point in time I would have been satisfied with only putting this in
evolution. But now I really think it should be in glib so other applications
can take advantage of it.

> Furthermore, I'm not really familiar with Islamic customs, but I find
> it hard to believe that the 99.9999% would care if the Islamic date
> function were in a separate library.

The users wouldn't, but I think the developers would.

> Anyway, I'm no Glib maintainer, just a Glib user, so it's not my
> call. But again, I do agree that these functions can be a valuable
> addition to the pool of free software - I just think it shouldn't be
> in Glib.

Me too. Its not my call either. Its up to the glib maintainer, I am willing to
write the code, its up to them wether they are willing to accept it or not.

Also note that having these functions won't really hamper, detract
performance, or bloat glib. I see no disadvantages of having this in glib.

Regards,
Ali