phpicalendar-devel — Mailing list for PHP iCalendar Developers

[PHPiCalendar-DEV] New mailing list

[Jared <xe...@si...>]

I added a new mailing list to the project. 
php...@li...

Every time a commit is done to our repository, an e-mail will be sent 
to that mailing list with what was changed and what the changes were. 
This will be used mostly to keep track of what is going on more than 
anything else. It will be important to log what the changes are in 
human readable form because that is also part of the e-mail and will be 
the easiest thing to have going on.

This is a read-only list. You can subscribe but do not send e-mail to 
that list. I mainly want it so those not in the project will know when 
things change and those of us in the project will know where everyone 
is at.

It doesn't work yet. I had to go through a series of steps to install 
the script that does it (syncmail) and when I committed it, it didn't 
stay executable so it can't run. I'm awaiting a support request to SF 
to be answered. They will have to fix it by hand.

Go ahead and subscribe if you wish. I didn't add anyone when I started 
it so you have to sign up yourself.

I think this list will allow us to add more people to the project. It's 
easier to know what everyone is doing when every change is sent to your 
inbox.

Let me know feedback on this idea. I didn't discuss it with anyone but 
I figured everyone would be up for it. Even if I'm the only one on the 
list, it'll still be worth it. :)

-Jared

Re: [PHPiCalendar-DEV] time zones

[Jared <xe...@si...>]

There should be no reason it doesn't work. It is in the array which 
holds the time zones. Without further information, I can only assume it 
was user error, as you are guessing.

-Jared

On Sunday, December 15, 2002, at 08:50 PM, Greg Westin wrote:

> I don't know why this would be, but I just heard from someone that the
> America/Los_Angeles time zone doesn't work.  Replacing it with 
> US/Pacific
> fixed it, he said.  I haven't tested it, maybe he just didn't type the
> underscore correctly or something.
>
> Greg
>
> ---
> gr...@gr...
> http://www.gregwestin.com/
> Contact info: http://www.gregwestin.com/contact.php
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

[PHPiCalendar-DEV] time zones

[Greg W. <gr...@gr...>]

I don't know why this would be, but I just heard from someone that the
America/Los_Angeles time zone doesn't work.  Replacing it with US/Pacific
fixed it, he said.  I haven't tested it, maybe he just didn't type the
underscore correctly or something.

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

Re: [PHPiCalendar-DEV] Translations

[Greg W. <gr...@gr...>]

This should fill in the blanks in the Japanese translation.  I can't
guarantee that they're right, as I haven't used a computer with Japanese
programs and whatnot for a couple years, but at least they work for now...

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

On Sun, 15 Dec 2002, Jared wrote:

> I'd be happy to have you help with the Japanese translation. I haven't
> had a chance to do it all myself yet. On top of that, I'm still
> learning and am not fluent. However, the bug you noticed it something I
> meant to fix. I know how, and it's relatively simple, I just haven't
> done it yet. Anything that is a sentence must be done this way (and in
> most cases, it is).
>
> The variable should be set to something like: "This site is %s." in
> English, and "kono webusaitoha %s des." and then run it through
> sprintf(). That's how I handle things like the error messages and the
> number of seconds the search took. I mean to change this for that, but
> I forgot. Oops.
>
> I also have part of 0.9 translations done so I'll commit those now. To
> read it, go to the open dialog of BBEdit and chose UTF-8 as the
> encoding, then open it. Without the byte-order mark, you must do this.
> If we included the byte-order mark it would be OK to just double click
> it but then there would be an extra character at the top of the web
> site because the browser doesn't know what else to do with it. It's a
> small price to pay, I think.
>
> Please let me know what else can be fixed. I know my Japanese isn't
> very good so I'd be happy to have help. The people I get help from are
> technologically illiterate and I'm afraid that makes things difficult
> to translate at times.
>
> Thanks.
>
> -Jared
>
> On Sunday, December 15, 2002, at 10:35 AM, Greg Westin wrote:
>
> > I was just reading through the Japanese translation, because I was
> > thinking about updating it to include all the new 0.9 stuff, when I
> > realized that we might need to rethink the way in which we do
> > translations, because not all languages use the same syntax as English.
> > For example, with the "RSS-enabled" text, the footer.inc.php file
> > writes
> > $this_site_is_lang and then the link that says "RSS-Enabled".  That
> > works
> > out find in English, because you get "This site is RSS-Enabled".  But
> > in
> > Japanese, the sentence structure (at least in the sentence Jared used)
> > is
> > such that the PHP would have to write some Japanese before RSS-Enabled,
> > and some after.  As it is, it says something more like "This site is.
> > RSS-Enabled", which sounds almost right in English because it just
> > looks
> > like stray punctuation, but it's totally wrong in Japanese.
> >
> > As a fix for this particular issue, I'd suggest that "kono uebusaito ha
> > desu." simply have the "desu." removed from the end, for the
> > $this_site_is_lang variable.  That would make things gramatically
> > correct.
> > (I can't figure out how to edit the file properly, or I'd do it
> > myself...
> > I can't get it to show up as Japanese in any text editor)  But this
> > speaks
> > to the larger issue of not always being able to rely on the sentence
> > structure being the same in other languages.  What do you think we
> > should
> > do to fix this?  I suppose one way would be to use functions rather
> > than
> > variables, and so for example calling rss_enabled_lang() would write
> > the
> > entire sentence plus link based on the language.  I would think that
> > if we
> > do that, we'll want the functions to return PHP code that can then be
> > interpreted in the file that calls the function, rather than returning
> > the
> > final HTML code, as then we don't have to deal with variable scope or
> > variable passing.
> >
> > Am I making any sense?  What does everyone else think?  Maybe this
> > isn't a
> > big enough issue to worry about right now, but it's something to think
> > about...
> >
> > Greg
> >
> > P.S.  Jared, if you could tell me how to edit that file properly, it
> > would
> > be much appreciated.  I generally use BBEdit for stuff like this that I
> > can't do in vim, and can write, save, and reopen files containing
> > Japanese, but for some reason just see gibberish in place of Japanese
> > when
> > I open japanese.inc.php.  Thanks!
> >
> > ---
> > gr...@gr...
> > http://www.gregwestin.com/
> > Contact info: http://www.gregwestin.com/contact.php
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Phpicalendar-devel mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>

Re: [PHPiCalendar-DEV] Translations

[Jared <xe...@si...>]

I'd be happy to have you help with the Japanese translation. I haven't 
had a chance to do it all myself yet. On top of that, I'm still 
learning and am not fluent. However, the bug you noticed it something I 
meant to fix. I know how, and it's relatively simple, I just haven't 
done it yet. Anything that is a sentence must be done this way (and in 
most cases, it is).

The variable should be set to something like: "This site is %s." in 
English, and "kono webusaitoha %s des." and then run it through 
sprintf(). That's how I handle things like the error messages and the 
number of seconds the search took. I mean to change this for that, but 
I forgot. Oops.

I also have part of 0.9 translations done so I'll commit those now. To 
read it, go to the open dialog of BBEdit and chose UTF-8 as the 
encoding, then open it. Without the byte-order mark, you must do this. 
If we included the byte-order mark it would be OK to just double click 
it but then there would be an extra character at the top of the web 
site because the browser doesn't know what else to do with it. It's a 
small price to pay, I think.

Please let me know what else can be fixed. I know my Japanese isn't 
very good so I'd be happy to have help. The people I get help from are 
technologically illiterate and I'm afraid that makes things difficult 
to translate at times.

Thanks.

-Jared

On Sunday, December 15, 2002, at 10:35 AM, Greg Westin wrote:

> I was just reading through the Japanese translation, because I was
> thinking about updating it to include all the new 0.9 stuff, when I
> realized that we might need to rethink the way in which we do
> translations, because not all languages use the same syntax as English.
> For example, with the "RSS-enabled" text, the footer.inc.php file 
> writes
> $this_site_is_lang and then the link that says "RSS-Enabled".  That 
> works
> out find in English, because you get "This site is RSS-Enabled".  But 
> in
> Japanese, the sentence structure (at least in the sentence Jared used) 
> is
> such that the PHP would have to write some Japanese before RSS-Enabled,
> and some after.  As it is, it says something more like "This site is.
> RSS-Enabled", which sounds almost right in English because it just 
> looks
> like stray punctuation, but it's totally wrong in Japanese.
>
> As a fix for this particular issue, I'd suggest that "kono uebusaito ha
> desu." simply have the "desu." removed from the end, for the
> $this_site_is_lang variable.  That would make things gramatically 
> correct.
> (I can't figure out how to edit the file properly, or I'd do it 
> myself...
> I can't get it to show up as Japanese in any text editor)  But this 
> speaks
> to the larger issue of not always being able to rely on the sentence
> structure being the same in other languages.  What do you think we 
> should
> do to fix this?  I suppose one way would be to use functions rather 
> than
> variables, and so for example calling rss_enabled_lang() would write 
> the
> entire sentence plus link based on the language.  I would think that 
> if we
> do that, we'll want the functions to return PHP code that can then be
> interpreted in the file that calls the function, rather than returning 
> the
> final HTML code, as then we don't have to deal with variable scope or
> variable passing.
>
> Am I making any sense?  What does everyone else think?  Maybe this 
> isn't a
> big enough issue to worry about right now, but it's something to think
> about...
>
> Greg
>
> P.S.  Jared, if you could tell me how to edit that file properly, it 
> would
> be much appreciated.  I generally use BBEdit for stuff like this that I
> can't do in vim, and can write, save, and reopen files containing
> Japanese, but for some reason just see gibberish in place of Japanese 
> when
> I open japanese.inc.php.  Thanks!
>
> ---
> gr...@gr...
> http://www.gregwestin.com/
> Contact info: http://www.gregwestin.com/contact.php
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

[PHPiCalendar-DEV] Translations

[Greg W. <gr...@gr...>]

I was just reading through the Japanese translation, because I was
thinking about updating it to include all the new 0.9 stuff, when I
realized that we might need to rethink the way in which we do
translations, because not all languages use the same syntax as English.
For example, with the "RSS-enabled" text, the footer.inc.php file writes
$this_site_is_lang and then the link that says "RSS-Enabled".  That works
out find in English, because you get "This site is RSS-Enabled".  But in
Japanese, the sentence structure (at least in the sentence Jared used) is
such that the PHP would have to write some Japanese before RSS-Enabled,
and some after.  As it is, it says something more like "This site is.
RSS-Enabled", which sounds almost right in English because it just looks
like stray punctuation, but it's totally wrong in Japanese.

As a fix for this particular issue, I'd suggest that "kono uebusaito ha
desu." simply have the "desu." removed from the end, for the
$this_site_is_lang variable.  That would make things gramatically correct.
(I can't figure out how to edit the file properly, or I'd do it myself...
I can't get it to show up as Japanese in any text editor)  But this speaks
to the larger issue of not always being able to rely on the sentence
structure being the same in other languages.  What do you think we should
do to fix this?  I suppose one way would be to use functions rather than
variables, and so for example calling rss_enabled_lang() would write the
entire sentence plus link based on the language.  I would think that if we
do that, we'll want the functions to return PHP code that can then be
interpreted in the file that calls the function, rather than returning the
final HTML code, as then we don't have to deal with variable scope or
variable passing.

Am I making any sense?  What does everyone else think?  Maybe this isn't a
big enough issue to worry about right now, but it's something to think
about...

Greg

P.S.  Jared, if you could tell me how to edit that file properly, it would
be much appreciated.  I generally use BBEdit for stuff like this that I
can't do in vim, and can write, save, and reopen files containing
Japanese, but for some reason just see gibberish in place of Japanese when
I open japanese.inc.php.  Thanks!

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

[PHPiCalendar-DEV] PHP iCalendar font

[Chad <ch...@ch...>]

Just looking at some fonts for the project.... Comments? Im leaning 
toward Triplex, it a more 'fun' font.

[PHPiCalendar-DEV] 1.0 Roadmap

[Chad <ch...@ch...>]

So I just wanted to quickly sketch out the 1.0 Roadmap. Currently Jared 
and I are busy with work/school but in another week or so have some 
time to really drive to 1.0. Here's what we're looking at:

0.9.1
I'd like to get bug fixes for 0.9.1 done soon, and get the release out, 
it will be the last until 1.0.

1.0 Beta
Zero Bugs in SourceForge
PRIVATE calendars / events support
LOCATION in events
THISANDAFTER support for deleting events
Multiple calendars (up to 6) being displayed.
Multi-user for *nix based systems
Timezones in prefs page
FTP upload (optional) in prefs page
Selection of multiple calendars via checkboxes in prefs page
Email this event for popups
Possible new styles
Zero feature requests (within reason)

1.0
Zero Bugs in SourceForge :-)

If there's anything I missed, let us know here. Jared and I will 
hopefully have time to do most of this and I'm sure there are others on 
the dev-list that will contribute code as well. We'll have to discuss 
how to do multiple calendars too, I know Jon(?) was working on 
something, I'd like to outline the end-user experience a bit.

-Chad

[PHPiCalendar-DEV] 0.9 out

[Chad <ch...@ch...>]

http://sourceforge.net/project/showfiles.php?group_id=62270

Still has some known issues, but need to get all the new features out 
for testing. That and we've fixed quite a bit in the last 5 weeks.

-Chad

Re: [PHPiCalendar-DEV] Check this out

[Chad <ch...@ch...>]

Heh, interesting. I should find out who wrote that. :-)

-C

On Thursday, December 5, 2002, at 08:20  PM, Jared wrote:

> http://developer.apple.com/internet/macosx/icalendarfiles.html
>
> Read about half way down. Cool! Chad, you know about this?
>
> (We should implement the WML)
>
> -Jared
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

[PHPiCalendar-DEV] Check this out

[Jared <xe...@si...>]

http://developer.apple.com/internet/macosx/icalendarfiles.html

Read about half way down. Cool! Chad, you know about this?

(We should implement the WML)

-Jared

Re: [PHPiCalendar-DEV] phpMyCal - editable calendars in phpicalendar

[Marook Z. K. <ma...@cr...>]

Cool! I'll give it a look tonight!


On mandag, dec 2, 2002, at 08:43 Europe/Copenhagen, Benjamin Levy wrote:

> I don't know if there's any interest, but I've wrapped up my code and=20=

> made it available here:
> http://dev.neb.net/phpMyCal/
>
> If you want to see it work, here's that bit of what I sent before.

	Jakob Peterh=E4nsel

"All You have to decide is what to do, with the time that is given to=20
you.
No one else can..."

Email: ja...@hj...
AIM: Marook

Re: [PHPiCalendar-DEV] phpMyCal - editable calendars in phpicalendar

[Jordan M. <jm...@MI...>]

Thanks for your work, it's great. It would be ideal if it didn't 
require MySQL, though, as this is another layer of configuration, 
installation, troubleshooting, and backing up that would need to be 
maintained separately from phpicalendar.

Jordan



On Sunday, December 1, 2002, at 01:54  AM, Benjamin Levy wrote:

> You make a good point here.  As far as integrating with iCal directly 
> I do think working directly with the files may be the way to go in the 
> future.  I think in my project I approached things from a slightly 
> different point of view, thinking of the server as being remote and 
> not read/writable by iCal (except for the DAV publishing currently 
> supported).  Given those limitations, this provides a way to enter 
> events away from your copy of iCal and still receive them later.  It's 
> possible, though, that the annoyances of not being able to edit the 
> online calendar from iCal will be too much, and make this all not very 
> useful.
>
> That said, there are a few other reasons for using a database - namely 
> I think it's much easier to deal with editing events in a database 
> than modifying a flat file.  Another issue is that many web hosting 
> providers do not provide anyway to give the web server/php write 
> permission to your files.  In my case, even writing to /tmp is 
> disabled.  As for using MySQL, it just seems to be a typical database 
> system these days.
>
> What I've built is sort of an independent thing that knows how to 
> write ics files.  That's the functionality I built first (minus any 
> user interface).  But my goal all along was to integrate with 
> phpicalendar, and so it can also just build the parsed master array 
> that phpicalendar uses.
>
> Ben

Re: [PHPiCalendar-DEV] phpMyCal - editable calendars in phpicalendar

[Benjamin L. <be...@um...>]

I don't know if there's any interest, but I've wrapped up my code and 
made it available here:
http://dev.neb.net/phpMyCal/

If you want to see it work, here's that bit of what I sent before.

My installation of this is at:
http://dev.neb.net/phpicalendar/

The default calendar is set to School, although it could be set to a 
phpMyCal calendar instead.  In the calendar list you'll see First Test 
Calendar, Number Two Calendar, and an ics.php... Webcal.  First Test 
and Number Two are the two testing calendars in the database.  First 
Test requires a password to make changes, while Number Two doesn't.  
The Webcal is actualy First Test feeding through the ics generation in 
order to test that $master_array is generated correctly by the phpMyCal 
bridge.

Ben

Re: [PHPiCalendar-DEV] Emailing events proof of concept

[Jon C. T. <cal...@wa...>]

On Sunday, December 1, 2002, at 06:40  PM, Chad wrote:

> We've moved to just passing a serialized array for the popup 
> information,
> that way just one field can contain all the information.

With some browsers and servers, that limits the amount of text per 
description.

In all cases, that leads to unnecessary duplication (such as my example 
of ten times per page).

But I can happily wait for templates to fix these things locally.

Actually, one thing that would help tremendously right now would be to 
centralize the generation of these links into a function in 
draw_functions.php.  That way we can all determine how we create these 
popups on a site by site basis, all in one place.  Right now that same 
work is done in five different files.

> Hover events are cute but of no real practical use(IMHO).

I agree.  I probably wouldn't use them here, but keeping the door open 
seems worthwhile.

Re: [PHPiCalendar-DEV] Emailing events proof of concept

[blaine <la...@us...>]

On Sunday, Dec 1, 2002, at 15:40 America/Vancouver, Chad wrote:

> Hover events are cute but of no real practical use(IMHO). No one knows 
> or expects them to be there and they can really drag in slow browsers. 
> This could make for a nifty Mod though.

Perhaps for version 1.0 or 1.1 some sort of squirrelmail-like plugin 
system (in conjunction with templates) could make it very easy to add 
this sort of thing. Just a little hook, and you can do all sorts of 
fancy things.

> My idea for 'Email this event' was this:
> A field and email button at the bottom of the todo or event popups. 
> The email mechanism you've built looks like  its working pretty well, 
> you could simply move all the code to an 'email.inc.php' file that we 
> can include anyplace. Bill your emails look nice, just needs a coat of 
> paint which I can do if needed.

One feature I'd really like to see along with this would be support for 
periodic emails; it would require cron, of course, but it would be 
great to be able to send calendar updates at regular intervals, so that 
people don't need to go to the website (or subscribe to an rss feed) to 
get calendars.

Something to go along with this (and the RSS feeds) is recently added 
or changed events. This could be done with the Last-Modified and 
Created property, in conjunction with Sequence. As I envision it (and 
this might not be to spec, but the rfc isn't very clear on this point), 
sequence would only be incremented for significant changes to the 
event; that way, people wouldn't be notified if a spelling mistake was 
fixed, etc. The RSS feed could be called with a "new events since..." 
parameter, with the default set in config.inc.php. Likewise, the email 
cron script could be given a similar argument.

With these features, system-hosted calendars would become useful for 
the many people that just subscribe to various mailing lists, rather 
than just web-addicted fiends or people with mozilla or ical. I'm so 
excited about what's happening with php icalendar. ;-)

If no-one puts a thumbs down to the above ideas, or takes them on, I'll 
start work on them sometime around the 15th.

b.

Re: [PHPiCalendar-DEV] Emailing events proof of concept

[Chad <ch...@ch...>]

We've moved to just passing a serialized array for the popup 
information, that way just one field can contain all the information. 
This is already in practice I believe with the TODO popup. The 
master_array does have some performance issues, Jared and I have gone a 
long ways to speed things up but we probably won't look at the issue 
again until we stop adding new code to it (for better calendar 
support). Using UIDs to speed up might work, but I wonder what the cost 
is to search the array vs. writing it. Also, as it is now, they are 
nicely separated and anyone can build their own displayer. Using UID 
makes this slightly more difficult.

Hover events are cute but of no real practical use(IMHO). No one knows 
or expects them to be there and they can really drag in slow 
browsers.This could make for a nifty Mod though.

My idea for 'Email this event' was this:
A field and email button at the bottom of the todo or event popups. The 
email mechanism you've built looks like  its working pretty well, you 
could simply move all the code to an 'email.inc.php' file that we can 
include anyplace. Bill your emails look nice, just needs a coat of 
paint which I can do if needed.

-C


On Sunday, December 1, 2002, at 02:15  PM, Jon C. Thomason wrote:

> I've given some thought to that issue, myself.  I think it would speed 
> up display times for users on a slow link.
>
> My main events calendar features a weekly repeating event with a 
> fairly lengthy description.  With things implemented as they are, that 
> one description is included up to ten times in the output of 
> month.php!  Once for each week it appears in the month view, and then 
> once again for each time it appears in the list of events at the 
> bottom.  Thank goodness it's not a daily repeating event.  :)
>
> So replacing those ten instances of description text with UIDs would 
> help a lot.  Especially since they delay the drawing of the main page 
> table, without contributing to its appearance.
>
> Incidentally, this would also solve a problem we encountered with CGI 
> deployments of PHP.  Event descriptions can't contain slashes, or PHP 
> will fail to load and the pop-ups will come up blank.  Our workaround 
> for now is to escape %2F with %1B.
>
> On the other hand, constructing the master_array is quite a lot of 
> start-up cost.  Arguably too much for just a single pop-up event 
> description.  Especially if the source calendar (or calendars!) are 
> located on a remote server.  The difference in load times would need 
> to be regained by good caching.  Or at least by having an optimized 
> path to look up a single event's description from a single calendar 
> file.
>
> Even if the decision is made to keep event descriptions in the code of 
> the main page, we can still reduce the duplication, and improve the 
> page display times:
>
> Add each description to an associative array based on UID.  Then 
> construct one JavaScript function at the end of the file (after the 
> main tables are closed).  That function would define the associative 
> array and its contents, look up the event description based on the 
> UID, and perform the pop-up there.
>
> That way repeating event descriptions would only appear once in the 
> file, and a browser would be able to draw the visible table even while 
> the as-yet invisible descriptions are still loading.
>
> The same associative array in JavaScript could eventually be used with 
> the DOM to show event descriptions as hover effects.  That wouldn't be 
> possible if we moved them entirely into event.php.
>
> On Sunday, December 1, 2002, at 03:54  PM, Bill Fenner wrote:
>
>> What I'd like to do is to change event.php so that instead of being
>> told all the useful info about the event, it gets passed the calendar,
>> date, time and uid -- that way it can grab the right stuff out of
>> the master_array to display, plus it can know those bits to pass them
>> along to email.php so there can be an "email this event" link from
>> the event.php popup .
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

Re: [PHPiCalendar-DEV] Emailing events proof of concept

[Bill F. <fe...@re...>]

>On the other hand, constructing the master_array is quite a lot of 
>start-up cost.

Yup.  I didn't think about this because I have save_parsed_cals='yes'.
I realized while I was working on this that I had no solution for
remote calendars.

I updated the javascript that day.php uses and created a new event popup
script, so http://irg.attlabs.net/~fenner/test/phpicalendar/day.php now
uses my whole imagined infrastructure for event popup and emailing events,
including carrying the UID around.  (The email.php page looks even worse
now that it's in the small window that event.php creates, sorry =)

There are a lot of tradeoffs here, it's clear that my current choices
suck for remote calendars, but I did think it was a good idea to get the
size of the generated page down for long descriptions.  Blah =)

  Bill

Re: [PHPiCalendar-DEV] Emailing events proof of concept

[Jon C. T. <cal...@wa...>]

I've given some thought to that issue, myself.  I think it would speed 
up display times for users on a slow link.

My main events calendar features a weekly repeating event with a fairly 
lengthy description.  With things implemented as they are, that one 
description is included up to ten times in the output of month.php!  
Once for each week it appears in the month view, and then once again 
for each time it appears in the list of events at the bottom.  Thank 
goodness it's not a daily repeating event.  :)

So replacing those ten instances of description text with UIDs would 
help a lot.  Especially since they delay the drawing of the main page 
table, without contributing to its appearance.

Incidentally, this would also solve a problem we encountered with CGI 
deployments of PHP.  Event descriptions can't contain slashes, or PHP 
will fail to load and the pop-ups will come up blank.  Our workaround 
for now is to escape %2F with %1B.

On the other hand, constructing the master_array is quite a lot of 
start-up cost.  Arguably too much for just a single pop-up event 
description.  Especially if the source calendar (or calendars!) are 
located on a remote server.  The difference in load times would need to 
be regained by good caching.  Or at least by having an optimized path 
to look up a single event's description from a single calendar file.

Even if the decision is made to keep event descriptions in the code of 
the main page, we can still reduce the duplication, and improve the 
page display times:

Add each description to an associative array based on UID.  Then 
construct one JavaScript function at the end of the file (after the 
main tables are closed).  That function would define the associative 
array and its contents, look up the event description based on the UID, 
and perform the pop-up there.

That way repeating event descriptions would only appear once in the 
file, and a browser would be able to draw the visible table even while 
the as-yet invisible descriptions are still loading.

The same associative array in JavaScript could eventually be used with 
the DOM to show event descriptions as hover effects.  That wouldn't be 
possible if we moved them entirely into event.php.

On Sunday, December 1, 2002, at 03:54  PM, Bill Fenner wrote:

> What I'd like to do is to change event.php so that instead of being
> told all the useful info about the event, it gets passed the calendar,
> date, time and uid -- that way it can grab the right stuff out of
> the master_array to display, plus it can know those bits to pass them
> along to email.php so there can be an "email this event" link from
> the event.php popup .

Re: [PHPiCalendar-DEV] Emailing events proof of concept

[Bill F. <fe...@re...>]

VTODOs work now too, try:

http://irg.attlabs.net/~fenner/test/phpicalendar/email.php?cal=vtodo&date=-2&time=1&uid=6A10FF75-FB43-11D6-BBBF-0003934FBC5E

  Bill

[PHPiCalendar-DEV] Emailing events proof of concept

[Bill F. <fe...@re...>]

Check out

http://irg.attlabs.net/~fenner/test/phpicalendar/email.php?cal=School&date=20021202&time=1030&uid=3805D39E-F1C7-11D6-A283-0050E4E60429

Since I am a programmer and not a web designer, it looks pretty awful,
but it tries to pick out the right bits of the ical source file to send
via email to the email address of your choice.  That's a sample event;
the 3 arguments are the 3 indexes to master_array[].  You should be able
to select any event from any of the sample calendars with the right
3 arguments.  Normal events work, todos don't work yet.

What I'd like to do is to change event.php so that instead of being
told all the useful info about the event, it gets passed the calendar,
date, time and uid -- that way it can grab the right stuff out of
the master_array to display, plus it can know those bits to pass them
along to email.php so there can be an "email this event" link from
the event.php popup .  This would change, e.g.

href="javascript:openEventInfo('First%2BAid%2B%2526%2BCPR', 'School', '10:30 AM', '11:30 AM', '')"

to

href="javascript:openEventInfo('School','20021202','1030','3805D39E-F1C7-11D6-A283-0050E4E60429')"

and event.php would return the right values from $master_array
instead of just returning what it was passed in.

What do you think?

  Bill

Re: ATTN: Authors (Re: [PHPiCalendar-DEV] 0.9 prep)

[blaine <la...@us...>]

Sorry. This wasn't supposed to go to the list. ;-)

move along, move along.

b.

On Sunday, Dec 1, 2002, at 10:29 America/Vancouver, blaine wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Even though none of my code has yet made it in, I plan on having quite 
> a bit of time in the next few weeks & months to contribute to the 
> project, and I want to get this message out of my inbox. ;-)
>
> Blaine Cook
> la...@us...
>
> - -or, if it won't be spam harvested-
>
> la...@re...
>
> b.
>
> On Tuesday, Nov 26, 2002, at 07:53 America/Vancouver, Jared wrote:
>
>> On Tuesday, November 26, 2002, at 01:08  AM, Chad wrote:
>>
>>> Also, Jared, if you could start an AUTHORS file, I'd like to get 
>>> everyone's name in who has contributed code and time in the project.
>>
>> With this in mind, if you have submitted any code which has been put 
>> into the project, please e-mail me personally (xe...@si...) with 
>> your full name and e-mail address you'd like in the AUTHORS file. 
>> Right now, I will add those of us that are listed on the SourceForge 
>> page but I need to know those who aren't but contribute.
>>
>> I will include the translators in this as well. I will use the names 
>> and e-mail addresses from the translation files for those so I won't 
>> need your information.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (Darwin)
>
> iD8DBQE96lUB0LjU31/N6YgRAnbzAJ96WmpdPKd9TcmToUfPHj0AqWMW1wCZAeRf
> XJw5cGzHfh601NwBxt+n9n8=
> =p3Dk
> -----END PGP SIGNATURE-----
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>

Re: ATTN: Authors (Re: [PHPiCalendar-DEV] 0.9 prep)

[blaine <la...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Even though none of my code has yet made it in, I plan on having quite 
a bit of time in the next few weeks & months to contribute to the 
project, and I want to get this message out of my inbox. ;-)

Blaine Cook
la...@us...

- -or, if it won't be spam harvested-

la...@re...

b.

On Tuesday, Nov 26, 2002, at 07:53 America/Vancouver, Jared wrote:

> On Tuesday, November 26, 2002, at 01:08  AM, Chad wrote:
>
>> Also, Jared, if you could start an AUTHORS file, I'd like to get 
>> everyone's name in who has contributed code and time in the project.
>
> With this in mind, if you have submitted any code which has been put 
> into the project, please e-mail me personally (xe...@si...) with 
> your full name and e-mail address you'd like in the AUTHORS file. 
> Right now, I will add those of us that are listed on the SourceForge 
> page but I need to know those who aren't but contribute.
>
> I will include the translators in this as well. I will use the names 
> and e-mail addresses from the translation files for those so I won't 
> need your information.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE96lUB0LjU31/N6YgRAnbzAJ96WmpdPKd9TcmToUfPHj0AqWMW1wCZAeRf
XJw5cGzHfh601NwBxt+n9n8=
=p3Dk
-----END PGP SIGNATURE-----

Re: [PHPiCalendar-DEV] phpMyCal - editable calendars in phpicalendar

[Benjamin L. <be...@um...>]

You make a good point here.  As far as integrating with iCal directly I=20=

do think working directly with the files may be the way to go in the=20
future.  I think in my project I approached things from a slightly=20
different point of view, thinking of the server as being remote and not=20=

read/writable by iCal (except for the DAV publishing currently=20
supported).  Given those limitations, this provides a way to enter=20
events away from your copy of iCal and still receive them later.  It's=20=

possible, though, that the annoyances of not being able to edit the=20
online calendar from iCal will be too much, and make this all not very=20=

useful.

That said, there are a few other reasons for using a database - namely=20=

I think it's much easier to deal with editing events in a database than=20=

modifying a flat file.  Another issue is that many web hosting=20
providers do not provide anyway to give the web server/php write=20
permission to your files.  In my case, even writing to /tmp is=20
disabled.  As for using MySQL, it just seems to be a typical database=20
system these days.

What I've built is sort of an independent thing that knows how to write=20=

ics files.  That's the functionality I built first (minus any user=20
interface).  But my goal all along was to integrate with phpicalendar,=20=

and so it can also just build the parsed master array that phpicalendar=20=

uses.

Ben

On Sunday, December 1, 2002, at 01:09  AM, Wilfredo S=E1nchez wrote:

>   Why use MySQL instead of editing the ics calendar files directly? =20=

> Or is this a independent thing that just happens to know how to=20
> generate ics files?
>
>   The reason I care is that I figure that iCal will become smart=20
> enough at some point that it will be able to open ics files over DAV=20=

> as read-write.  Which means the authoritative file can on the net=20
> instead of on one of my computers, and all my Macs can edit it using=20=

> iCal (no iSync required) and other software (eg. phpicalendar) can=20
> also edit it.
>
>   If you store the data in MySQL and generate ics files from there,=20
> this wouldn't be possible for those calendars; the only way to edit=20
> them would be though your app.  Plus it requires MySQL, which isn't=20
> all that easy to set up and manage.
>
> 	-wsv
>
>
> On Saturday, November 30, 2002, at 02:50  PM, Benjamin Levy wrote:
>
>> phpMyCal is an interface for a schedule database using MySQL.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T=20
> handheld. Power & Color in a compact size!=20
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

Re: [PHPiCalendar-DEV] phpMyCal - editable calendars in phpicalendar

[<wsa...@ws...>]

   Why use MySQL instead of editing the ics calendar files directly?  Or 
is this a independent thing that just happens to know how to generate 
ics files?

   The reason I care is that I figure that iCal will become smart enough 
at some point that it will be able to open ics files over DAV as 
read-write.  Which means the authoritative file can on the net instead 
of on one of my computers, and all my Macs can edit it using iCal (no 
iSync required) and other software (eg. phpicalendar) can also edit it.

   If you store the data in MySQL and generate ics files from there, 
this wouldn't be possible for those calendars; the only way to edit 
them would be though your app.  Plus it requires MySQL, which isn't all 
that easy to set up and manage.

	-wsv


On Saturday, November 30, 2002, at 02:50  PM, Benjamin Levy wrote:

> phpMyCal is an interface for a schedule database using MySQL.