Re: Personal Calendar Server Volunteer? (fwd)

[Ali Abdin <ALIABDIN aucegypt edu>]

> While you're right that using a different *time* system is probably 
> irrelevant, I do think that the day should start at the correct time. 
>  At least for the Hebrew calendar, it would be simply *wrong* to say 
> that the day changes at midnight.  For example, right now, it's 1:00 
> PM on 1 Adar I 5760.  In 7 hours, however, it will be 8:00 PM on 2 
> Adar I 5760- the day will have changed at sunset, localtime.  8:00 PM 
> on 1 Adar I 5760 was "yesterday" on the Gregorian calendar (16 hours 
> or so ago).

Nononono - the date wouldn't have rolled over yet. e.g. it would still be 
8PM on 1 Adar I 5760. Rollover will occur at midnight. We'll just be 
using Hebrew dates with normal time. I do not see a problem with this 
(except that its not really correct)....sooooo its 1PM 1 Adar I 5760 - in 
7 hours it will be 8PM on 1 Adar I 5760 - at midnight it will be 00:00 on 
2 Adar I 5760
  
> >> By modular I simply meant that whatever hacking you do to get an 
> >> Islamic calendar working in gnomecal, you implement some sort of 
> >> generic calendar abstraction so that if someone else (me, for 
> >> example) wants to write another calendar module, we can add it in 
> >> later.  Basically, a "calendar module" should need to provide the 
> >> conversion functions, some functions to work with the lengths and 
> >> names of months and years, and that should be enough.
> >
> >I'm beginning to think this would be better than an XML file - 
> Although
> >an XML file still could work - for example, you would just 
> 'designate' a
> >function as 'leap-year' for example and then the code would 'handle' 
> the
> >leap-yearness based on the type of the calendar.
> 
> Eh?  I still think you're conflating two issues.  While a "module" 
> could read its leap years from an XML file if it chose to, the 
> gnomecal core should simply ask the module how many months/days there 
> are in the year, and let the module do whatever it wants.  So that if 
> one module uses an algorithm, so be it.  If another uses an XML 
> lookup, ditto.

What my original intention/meaning was that you would not have "modules" 
you would have XML files - these /are/ the modules - gnomecal would just 
parse each 'calendar' and handle it - Like I said, i'm beginning to think 
this is not a good idea. My question now is - how should these modules be 
handles (shared libraries?)
 
> >I'm beginning to think a standard API would be better - How would 
> you go
> >about working in 'calendar modules' in gnome-pim then? I don't like 
> the
> >idea of making Gregorian a module (more trouble than its worth? most 
> >people will be using Gregorian). For example each module should have 
> a:
> >
> >native_to_gregorian and gregorian_to_native function - The user can 
> >'view' the schedule stuff in their 'native' format - but internally 
> the
> >'events/schedule' would be stored using Gregorian?
> 
> Internally, events will be stored in something akin to:
> 
> typedef struct { time_t t, TimeZone* tz } GnomeCalTimeType;
> 
> (currently it's just time_t, but it's going to have to change for 
> other reasons).
> 
> So let's assume you're using the UI in Islamic mode:
> 
> 1. You open the event editor and schedule an event for 2 Dhu al-Qada 
> 1420, 20:00 UTC. (If Emacs' implementation is correct, that's about 
> an hour and a half from now.)
> 
> 2. The client calls islamic_to_time_t () to convert that time, and 
> calls the standard add_event function.

sounds easy enough - so each calendar is a shared lib of some sort with 
two external functions? islamic_to_time_t () and time_t_to_islamic? or 
maybe i'm just overlooking something here? (I'm just picking of thoughts 
from the top of my head - haven't really sat down to think about it)
 
> What else do you need?  The client/server interface, as I understand 
> it (since Federico is still working it), is that the client requests 
> the server send it all events within a specific range of time_t's, 
> such as a day or a month.  So your UI in Islamic mode would simply 
> calculate the appropriate time_t's for a given date's start and end 
> and use the existing interface.

I mail'd federico about this and i think you saw that mail on this list - 
but you didn't see his response. Basically - no hacking on evolution. He 
basically said "just put that functionality in gnome-pim" - that way when 
the Personal Calendar Server stuff is complete/done then things can be 
'forwardported' to evolution (e.g. lunar calendar stuff) - and anyway, 
federico I think is basing his code on gnome-pim (i.e. he reads gnome-pim 
source and then integrates it the evolution-way)

> For that matter, doing the sunset-to-sunset days wouldn't be that 
> much more difficult- just compute the time_t for sunset, rather than 
> midnight on the given day.  Libastro can do that.

I'm beginning to think (without reading any source) it would be a trivial 
matter to do (e.g. just have a 'rollover' time and do calculations of 
date based off of that) - libastro would just calculate (the constantly 
changing) 'rollover' time (sunset)
 
> The rest of the changes are UI issues- changing date formats, date 
> labels, drop down boxes, etc.  You can either implement these changes 
> in the core gnomecal/evolution client, or you could, in theory, write 
> a separate client, since Evolution is going to have a client-server 
> separation in the client anyway.  I think it's neater to do it in the 
> main client, provided the widget changes required aren't too hairy.  
> If you're willing to use a simpler interface, however, it may be 
> easier to code one from scratch and then just use the client-server 
> CORBA interface.

See previous note on evolution (basically - its not ready yet) - so it 
would be better to work with gnomecal. The UI might be a pain to change 
(hence i suggested i'd work on my own app). Is this an instance where 
libglade would come in handy? (a glade file UI for each calendar)

> You have two options for loading/saving, as I see it:
> 
> 1. Do a Gregorian -> Islamic conversion at load-time and an Islamic ->
>  Gregorian at save-time- this means inserting calls to your 
> conversion routines into the load and save routines we already have.
> 
> 2. Define a standardized way of storing Islamic dates, submit it to 
> the IETF as a proposed extension to the iCalendar specification, and 
> then hack it into the parsing library (libical) or convince its 
> author to implement your new extension.
> 
> The latter is more socially-redeeming and will theoreticlly 
> interoperate with other systems.  The former seems a lot simpler.  
> Your call. :)

hahaha - I think I'll stick to #1. If i can't even understand 
specifications, then obviously, i can't even write them ;)

Hmmm - wouldn't it be 'theoretically' better to store the date based on 
time_t though?
 
> >> (I think this is actually a perverse variant of the multiple 
> timezone
> >> scheduling problem...  Sometimes you want to schedule an event at 
> >> 9:00 wherever you are, but sometimes you want everyone to be doing 
> it
> >> at the same precise time, regardless of their timezone.)
> >
> >Yeah - this is a big problem. What you could do is when specifying 
> an
> >appointment date have a 'toggle' button underneath asking them for 
> it to
> >be a 'days to appointment' (e.g. 60 days from now) or an exact date 
> >(month 3, day 1). Naturally you should be able to also specify a 
> >gregorian date (or any other date) and have it naturally interpreted 
> to
> >your native format (through the native_to_gregorian and 
> gregorian_to_native)
> 
> That's generally the same UI concept Federico and I have discussed 
> for handling group scheduling when the participants are in multiple 
> timezones- you need to give the user the ability to select whether 
> they want "fixed" or "floating" time.  I don't know how it well it 
> will actually work as a UI, but I can't think of a better way either.
> 
> This actually complicates the load/save issue above: fixed times 
> (month 3, day 1) can't be stored as Gregorian dates, since their 
> Gregorian equivalent is indeterminant.  You'll need to define some 
> way to store an indicator, whether in an X-Property or a full-scale 
> date representation....

Shit - i didn't think of that point at all :) Whats an X-property or a 
full-scale representation?

Here's an idea - for 'un-fixed' date (which i have no idea how it would be 
stored) - anyhow, it could graphically show some sort of 'shadow' on the 
the next day (and previous day?) - this is just to indicate that the 
appointment could be on either date.

Hmmm - storage in gregorian would be a pain here
 
> Hope this helps- feel free to keep bouncing ideas off me and the 
> list.  Note that gnome-pim HEAD is currently in feature freeze for a 
> 1.2 release, so you should hold off on committing/submitting any 
> patches for the time being.

don't have a CVS account so its no problem here...Actually - i'm not 
really coding for a while (after 3 days of trying to get Civ:CTP 
(windows) to work, it worked when i used a different hard disk (I guess 
driver problems - uggh) anyway, as you can guess - I'm too busy playing 
Civ:CTP in windows to code) - anyway, my point is - i'm trying to gather 
as much data as I possible can...

You've really simplified what I have to do a lot (you basically relegated 
me to a 'module' writer) - but anyway. Can we get some sort of standard 
going as to how we want to have these calendar 'modules'? (e.g. shared 
libs (which would require a specific exported API), or just dirs with 
files within the toplevel gnomecal tree (e.g. code a new module, put the 
sources in CVS and hook it up with configure.in, Makefile.am, and other 
magical stuff) (oh, and prolly mess with gnomecal source to 'integrate 
it')...Once that happens I can actually start coding on my 'islamic' 
module as a 'demo-module'