phpicalendar-devel

RE: [PHPiCalendar-DEV] Outlook and iCal addition into phpicalendar

[svens <sv...@de...>]

A dedicated pop3 (could be imap) account is used to receive the mail with
the *.ics attachments;
On each request (index, day, week, month, year) the mailserver is checked
for new additions and, if so, they'll be added into the calender associated
with the senders email address;
It's quite easy to set it up in a way that anyone can ad through this way
into a public calendar, but who would want that??
 
Anyway, when things can be added, they should also be delete-able, by the
adder that is. I altered the event.php in such way that the adder can delete
the item from its calendar, on uid-basis, from within the event popup;
 
Once the delete-option was made, it was also possible to add two other
options into the event popup: export item to outlook or to iCal, also on
uid-basis.
 
I did it in the last three evenings, so it's not fully finished/tested, but
also it was surprisingly simple. 
So now I just wonder why I can't find any similar addition to phpicalendar.
 
Why can mail_into_phpicalendar be preferable to just plain uploading of a
whole calendar or using webcal reference? 
Well, since anyone is used to his/her email application, one can expect them
to easily use it for emailing a calendar-item. 
Making it in your own system and then sending it, provides a backup, id's
and all the necessary data.
Using a form to add into phpicalender, would require a lot of choices,
possibilities, checks and balances.
 
I am wondering if anyone has tried the same and if i have overlooked any
(future) problem.


>It seems to me that you want to do (at the end of the dev) something
>like Outlook, with event invitation, isn't it ?

No event invitation. 
The quest:
Around a common subject, different people are involved. I made one general
calendar, which I as moderator will update (using outlook and outlook2ical
(a vb-macro)). For each (couple of) participant(s) I've setup a own calendar
-> Petrus, Paulus, Lucas, etc...
The solution:
Each of them can email an event as attachment (either from Outlook or iCal)
to a certain emailaddress. Whenever a any user/viewer of the calendar
changes view a tiny little php-script is launched, using imap_mail_etc,
checking for mail with attachments, checking attachments for events, merging
them into the existing phpicalendar *.ics that is associated with their
senders emailaddress. It works just fine!
The alternatives:
1. moderation through the administrator (takes his time and delay in
update);
2. update a own calendar in a shared map (needs experienced participants,
trust in macro's and the use of passwords, etc);
3. update a own calendar in a private map (needs experienced participants,
trust in macro's, etc);
4. moderation through a webform (see previous mail);

Now, I reckon invitation can easily be done, but I was not suggesting it.

>I'm not sure for Mozilla calendar (Outlook is not dealing with
>standard ICS format, so ...), but iCal allows you to update published
>calendar on every changes, so this is doing what you want, no ?

Now Outlook has the possibility to import *.ics calendars as a whole, after
downloading it OR to open one (generated on the fly) within Outlook and save
it, etc.
Also Outlook has the possibility to send an opened event to send as a *.ics.
(top-menu: Actions -> Send as *.ics). It than contains all the necessary
data (uid, timezones, whatever). With iCal one can do exactly the same.

Given the above, the suggested (and working!!) solution is not only fast and
efficient, it's also phpicalendar-updating for dummy's. For anyone who's
able to use its calendar and emailprogramm, can than update a calendar
(s)he's authorized to, by email-recognition.
Again, it was very very simple.

>The first goal of this project is to publish calendars on a network.
>I agree that something interesting would be to add is a way to edit
>calendars. Various hacks had been done on this subject, and
>particularly something to send an email to the calendar owner to book
>time. 
This sounds like the alternative 1., which requires an administrators
interaction. I hope I now explained well enough that my suggestion is
without any human interaction and yet with very limited programming.

Of course than also deleting had to be added, and I did.
Doing so also save item to outlook resp. save item to iCal was easily made.

RE: [PHPiCalendar-DEV] Outlook and iCal addition into phpicalendar

[svens <sv...@de...>]

I am so sorry that I express myself so poorly.

Authentication takes place by the senders-email address, only registered
emailaddresses can add, and only into the calendars they are associated
with, according to an array/database set up by the administrator. (Now I am
not discussing an open calendar, in which case no authentication would take
place, of course). This can be done with the php imap-functions.

The uid-basis is the identification of the events themselves for tracking
them in the calendar and deleting or retrieving them.

I don't know much about spoofing anothers email-address, but I reckon an
important element of that is that one has to know the registered
emailaddress in order to spoof it. In the mail2icalendar I made, this
emailaddress is not revealed, so I reckon it's spoof proof enough.

>I like the idea of being able to e-mail in events simply because I  
>wish we had a system that allowed multiple users to edit a calendar,  
>and programs like iCal (and Outlook, I assume) can e-mail a  
>small .ics file with just one event, and most people are comfortable  
>using e-mail.  ...

>At the end of the day, though, if this functionality is already ready  
>to go, I certainly wouldn't object to trying it out and potentially  
>including it, simply noting to users that it is a method without  
>security.  

I'll make a test calendar, anyone who wishes to try it, can mail me with
their address. I'll also publish the (yet simple code) I used. Of course
there is lot room for improvement, but for me, it already works.

Mail me at: svens dds nl

Re: [PHPiCalendar-DEV] Emailed Events, Editing Events, and Superglobals

[Wesley M. <we...@we...>]

Hi People,

Sorry I haven't been active on the project much lately. Been busy  
with other things.

Unfortunately, authentication based solely upon the sender's email  
address is incredibly insecure, and easily spoofed. So I'm afraid  
that cannot be used. It's easy enough to identify the email address  
being used to update a calendar by monitoring the inbound email  
traffic to that server.

Since it seems the primary motivation of this system is to provide  
the addition of .ics events to an existing calendar, I believe a good  
solution would be to allow upload of .ics files via the admin page to  
add the contents of that .ics file to an existing calendar. This  
still allows remote additions, while also remaining within the  
authentication framework currently used to add/delete calendars.  
There's no need to make it full-featured if we only support insertion  
of events via the admin interface. However, there is the issue of  
merging identical events, as I believe you receive .ics files back  
when someone accepts your meeting invitation, for example. So you  
would have to identify the matching event (there is a unique event  
ID, I think?) and update the fields appropriately in the master .ics  
file.

Seems fair enough that if you are the administrator, then adding a  
feature to delete and possibly even edit events (since the previous  
paragraph added the ability to update existing events) could be done  
because PHP iCalendar knows you are the administrator. I see mention  
of deleting events in one of the previous emails.

Also sorry I didn't provide any more input on the topic of sanitizing  
user input earlier. Nicolas, I think you said you will work on this?  
If I read the emails right. An easy way to do this would be to parse  
the superglobals such as _GET and _POST into a registry object,  
perform sanity checks on the values as you register them, and then  
completely clean-out the contents of those superglobals so that  
attempts to access them elsewhere will just fail. Then provide  
methods to access the registry contents like as Hashtable.

The sanity checks on the input could be specified as regular  
expressions in a central file, which happens to be the ONLY file the  
superglobal registry file pulls in. Any edits to the registry file  
later on would be easy to flag as suspicious, and same as any changes  
to the regular expressions definition file. If you allow the sanity  
checks to be defined in random places, then it becomes too hard to  
keep track.

Later,
--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] Emailed Events, Editing Events, and Superglobals

[Jim Hu <ji...@ta...>]

Re: Editing events via email
This sounds like a mod that would not be part of the main  
phpicalendar development.  I worry that it would be hard to make this  
compatible with regular ical use - there are issues related to file  
locking etc. that may be problematic (and I'm also hoping CalDAV will  
serve the desired purpose).

I would like to see svens make it available, and with appropriate  
disclaimers I think it (and other mods like the editing system  
someone else has on the bbs) could be hosted on the sourceforge files/ 
packages page.  How does that sound?  If I was going to put time into  
making an editable system, I agree with Greg that I'd just make a web  
interface.  I'd set up a mysql backend for the persistence layer and  
just have events and todos as record types.  I bet it wouldn't be too  
hard to have the database output populate the master array...in fact,  
I thought someone had a project to do that already with phpicalendar  
1.x.

Re: Superglobals

I hadn't been thinking of doing it OO, but that's probably a good  
idea.  If I understand Wesley, we'd create a class globals (or some  
similar name).  The object constructor method would do something like

foreach ($_REQUEST as $key=>$val){
	#code to handle the variable namespace from $_GET or $_POST or  
$_COOKIE or from config.inc.php
	...probably a big switch statement
	unset $_GET[$key];
	unset $_POST[$key];
	unset $_REQUEST[$key];
}

The globals object would then have methods to return the sanitized  
values.  Then init.inc.php would be something like
$globals = new globals
and $globals would be used as a global object variable as needed.   
Instances of $getdate, for example, would be replaced by $globals- 
 >getdate

Is that about right? I like this, since one can just declare $globals  
as global instead of enumerating lots of variable names.

In the non-OO approach I've used elsewhere, I just move all the  
values from $_REQUEST[$key] into a new array $clean[$key] after doing  
value validation via a large switch statement.  In the codebase, we'd  
just do a global search and replace for $_GET, $_POST, and $_REQUEST  
to $clean.

Jim

On Apr 28, 2006, at 6:10 PM, Wesley Miaw wrote:

> Hi People,
>
> Sorry I haven't been active on the project much lately. Been busy  
> with other things.
>
> Unfortunately, authentication based solely upon the sender's email  
> address is incredibly insecure, and easily spoofed. So I'm afraid  
> that cannot be used. It's easy enough to identify the email address  
> being used to update a calendar by monitoring the inbound email  
> traffic to that server.
>
> Since it seems the primary motivation of this system is to provide  
> the addition of .ics events to an existing calendar, I believe a  
> good solution would be to allow upload of .ics files via the admin  
> page to add the contents of that .ics file to an existing calendar.  
> This still allows remote additions, while also remaining within the  
> authentication framework currently used to add/delete calendars.  
> There's no need to make it full-featured if we only support  
> insertion of events via the admin interface. However, there is the  
> issue of merging identical events, as I believe you receive .ics  
> files back when someone accepts your meeting invitation, for  
> example. So you would have to identify the matching event (there is  
> a unique event ID, I think?) and update the fields appropriately in  
> the master .ics file.
>
> Seems fair enough that if you are the administrator, then adding a  
> feature to delete and possibly even edit events (since the previous  
> paragraph added the ability to update existing events) could be  
> done because PHP iCalendar knows you are the administrator. I see  
> mention of deleting events in one of the previous emails.
>
> Also sorry I didn't provide any more input on the topic of  
> sanitizing user input earlier. Nicolas, I think you said you will  
> work on this? If I read the emails right. An easy way to do this  
> would be to parse the superglobals such as _GET and _POST into a  
> registry object, perform sanity checks on the values as you  
> register them, and then completely clean-out the contents of those  
> superglobals so that attempts to access them elsewhere will just  
> fail. Then provide methods to access the registry contents like as  
> Hashtable.
>
> The sanity checks on the input could be specified as regular  
> expressions in a central file, which happens to be the ONLY file  
> the superglobal registry file pulls in. Any edits to the registry  
> file later on would be easy to flag as suspicious, and same as any  
> changes to the regular expressions definition file. If you allow  
> the sanity checks to be defined in random places, then it becomes  
> too hard to keep track.
>
> Later,
> --
> Wesley Miaw
> we...@we...
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

Re: [PHPiCalendar-DEV] Emailed Events, Editing Events, and Superglobals

[Wesley M. <we...@we...>]

Hi Jim,

I agree with your decision on the event editing.

As for superglobals, I didn't necessarily mean to treat it as a  
global object. The array approach works just as well and might be  
easier for everyone. But the OO approach might mean more control over  
security. I'm not really sure. You could just use $globals->get("")  
so that you don't need to modify the globals class that much whenever  
a new value needs to be exposed. Since there's no $globals->set(),  
which you can't prevent when using an array, you're safe.

The advantage of defining regular expressions to match against the  
global values in a separate file is that you can make your switch  
statement go away and instead do something like (this is rough, and I  
haven't got the PHP syntax right):

foreach ($key in $_REQUEST) {
     $regexp = $global_regexps[$key];
     if (!defined $regexp) next;
     preg_match($_REQUEST[$key], $regexp, $matches);
     $global_store[$key] = $matches[1];
     unset $_POST[$key];
     unset $_GET[$key];
     unset $_REQUEST[$key];
}

Later,
Wes

On Apr 28, 2006, at 5:43 PM, Jim Hu wrote:

> Re: Editing events via email
> This sounds like a mod that would not be part of the main  
> phpicalendar development.  I worry that it would be hard to make  
> this compatible with regular ical use - there are issues related to  
> file locking etc. that may be problematic (and I'm also hoping  
> CalDAV will serve the desired purpose).
>
> I would like to see svens make it available, and with appropriate  
> disclaimers I think it (and other mods like the editing system  
> someone else has on the bbs) could be hosted on the sourceforge  
> files/packages page.  How does that sound?  If I was going to put  
> time into making an editable system, I agree with Greg that I'd  
> just make a web interface.  I'd set up a mysql backend for the  
> persistence layer and just have events and todos as record types.   
> I bet it wouldn't be too hard to have the database output populate  
> the master array...in fact, I thought someone had a project to do  
> that already with phpicalendar 1.x.
>
> Re: Superglobals
>
> I hadn't been thinking of doing it OO, but that's probably a good  
> idea.  If I understand Wesley, we'd create a class globals (or some  
> similar name).  The object constructor method would do something like
>
> foreach ($_REQUEST as $key=>$val){
> 	#code to handle the variable namespace from $_GET or $_POST or  
> $_COOKIE or from config.inc.php
> 	...probably a big switch statement
> 	unset $_GET[$key];
> 	unset $_POST[$key];
> 	unset $_REQUEST[$key];
> }
>
> The globals object would then have methods to return the sanitized  
> values.  Then init.inc.php would be something like
> $globals = new globals
> and $globals would be used as a global object variable as needed.   
> Instances of $getdate, for example, would be replaced by $globals- 
> >getdate
>
> Is that about right? I like this, since one can just declare  
> $globals as global instead of enumerating lots of variable names.
>
> In the non-OO approach I've used elsewhere, I just move all the  
> values from $_REQUEST[$key] into a new array $clean[$key] after  
> doing value validation via a large switch statement.  In the  
> codebase, we'd just do a global search and replace for $_GET,  
> $_POST, and $_REQUEST to $clean.
>
> Jim
>
> On Apr 28, 2006, at 6:10 PM, Wesley Miaw wrote:
>
>> Hi People,
>>
>> Sorry I haven't been active on the project much lately. Been busy  
>> with other things.
>>
>> Unfortunately, authentication based solely upon the sender's email  
>> address is incredibly insecure, and easily spoofed. So I'm afraid  
>> that cannot be used. It's easy enough to identify the email  
>> address being used to update a calendar by monitoring the inbound  
>> email traffic to that server.
>>
>> Since it seems the primary motivation of this system is to provide  
>> the addition of .ics events to an existing calendar, I believe a  
>> good solution would be to allow upload of .ics files via the admin  
>> page to add the contents of that .ics file to an existing  
>> calendar. This still allows remote additions, while also remaining  
>> within the authentication framework currently used to add/delete  
>> calendars. There's no need to make it full-featured if we only  
>> support insertion of events via the admin interface. However,  
>> there is the issue of merging identical events, as I believe you  
>> receive .ics files back when someone accepts your meeting  
>> invitation, for example. So you would have to identify the  
>> matching event (there is a unique event ID, I think?) and update  
>> the fields appropriately in the master .ics file.
>>
>> Seems fair enough that if you are the administrator, then adding a  
>> feature to delete and possibly even edit events (since the  
>> previous paragraph added the ability to update existing events)  
>> could be done because PHP iCalendar knows you are the  
>> administrator. I see mention of deleting events in one of the  
>> previous emails.
>>
>> Also sorry I didn't provide any more input on the topic of  
>> sanitizing user input earlier. Nicolas, I think you said you will  
>> work on this? If I read the emails right. An easy way to do this  
>> would be to parse the superglobals such as _GET and _POST into a  
>> registry object, perform sanity checks on the values as you  
>> register them, and then completely clean-out the contents of those  
>> superglobals so that attempts to access them elsewhere will just  
>> fail. Then provide methods to access the registry contents like as  
>> Hashtable.
>>
>> The sanity checks on the input could be specified as regular  
>> expressions in a central file, which happens to be the ONLY file  
>> the superglobal registry file pulls in. Any edits to the registry  
>> file later on would be easy to flag as suspicious, and same as any  
>> changes to the regular expressions definition file. If you allow  
>> the sanity checks to be defined in random places, then it becomes  
>> too hard to keep track.
>>
>> Later,
>> --
>> Wesley Miaw
>> we...@we...
>>
>>
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Phpicalendar-devel mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] Outlook and iCal addition into phpicalendar

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

I haven't thought about this all that closely, but I have one big  
question about this: how does authentication take place?  This e-mail  
says 'on a uid-basis', which I assume means that only e-mail  
addresses from the same domain are accepted, and from addresses are  
matched with their corresponding local users.  However, this does not  
ensure that the person adding or deleting the event in question is  
the person you think they are.  Someone could simply spoof another  
person's e-mail address to change the entire calendar.  Perhaps  
security isn't essential here, but it seems like there should at  
least be a password checked.

Maybe you can be reasonably confident that the sender is who s/he  
says s/he is if your mail server only accepts local connections and  
requires authentication, but that's such a rare condition that it  
makes the number of potential users vanishingly small.

I like the idea of being able to e-mail in events simply because I  
wish we had a system that allowed multiple users to edit a calendar,  
and programs like iCal (and Outlook, I assume) can e-mail a  
small .ics file with just one event, and most people are comfortable  
using e-mail.  However, anything beyond simply mailing the .ics file  
via an unaltered e-mail generated by iCal seems like too much -- why  
not just have a web interface?  Having administered a Mailman mailing  
list server after a Majordomo one in the past, I know that even as an  
administrator I hated having to figure out which arcane command I  
needed to use, and what address I needed to send it to; it was  
generally much easier to use the Mailman web interface unless I  
needed to script something or route the output of a command somewhere  
or something like that, and then I'd use the command line.

At the end of the day, though, if this functionality is already ready  
to go, I certainly wouldn't object to trying it out and potentially  
including it, simply noting to users that it is a method without  
security.  Hopefully in the future CalDAV will be ready to go and  
applications like iCal will support it natively, so that PHPiCalendar  
doesn't have to do all this work, but in the meantime it would be  
great if this little calendar-displaying application could support  
some basic multi-user editing to fill that void.

Greg
---
http://www.gregwestin.com
Contact Info: http://www.gregwestin.com/contact.php


On Apr 28, 2006, at 11:32 AM, svens wrote:

>
> A dedicated pop3 (could be imap) account is used to receive the  
> mail with
> the *.ics attachments;
> On each request (index, day, week, month, year) the mailserver is  
> checked
> for new additions and, if so, they'll be added into the calender  
> associated
> with the senders email address;
> It's quite easy to set it up in a way that anyone can ad through  
> this way
> into a public calendar, but who would want that??
>
> Anyway, when things can be added, they should also be delete-able,  
> by the
> adder that is. I altered the event.php in such way that the adder  
> can delete
> the item from its calendar, on uid-basis, from within the event popup;
>
> Once the delete-option was made, it was also possible to add two other
> options into the event popup: export item to outlook or to iCal,  
> also on
> uid-basis.
>
> I did it in the last three evenings, so it's not fully finished/ 
> tested, but
> also it was surprisingly simple.
> So now I just wonder why I can't find any similar addition to  
> phpicalendar.
>
> Why can mail_into_phpicalendar be preferable to just plain  
> uploading of a
> whole calendar or using webcal reference?
> Well, since anyone is used to his/her email application, one can  
> expect them
> to easily use it for emailing a calendar-item.
> Making it in your own system and then sending it, provides a  
> backup, id's
> and all the necessary data.
> Using a form to add into phpicalender, would require a lot of choices,
> possibilities, checks and balances.
>
> I am wondering if anyone has tried the same and if i have  
> overlooked any
> (future) problem.
>
>
>> It seems to me that you want to do (at the end of the dev) something
>> like Outlook, with event invitation, isn't it ?
>
> No event invitation.
> The quest:
> Around a common subject, different people are involved. I made one  
> general
> calendar, which I as moderator will update (using outlook and  
> outlook2ical
> (a vb-macro)). For each (couple of) participant(s) I've setup a own  
> calendar
> -> Petrus, Paulus, Lucas, etc...
> The solution:
> Each of them can email an event as attachment (either from Outlook  
> or iCal)
> to a certain emailaddress. Whenever a any user/viewer of the calendar
> changes view a tiny little php-script is launched, using  
> imap_mail_etc,
> checking for mail with attachments, checking attachments for  
> events, merging
> them into the existing phpicalendar *.ics that is associated with  
> their
> senders emailaddress. It works just fine!
> The alternatives:
> 1. moderation through the administrator (takes his time and delay in
> update);
> 2. update a own calendar in a shared map (needs experienced  
> participants,
> trust in macro's and the use of passwords, etc);
> 3. update a own calendar in a private map (needs experienced  
> participants,
> trust in macro's, etc);
> 4. moderation through a webform (see previous mail);
>
> Now, I reckon invitation can easily be done, but I was not  
> suggesting it.
>
>> I'm not sure for Mozilla calendar (Outlook is not dealing with
>> standard ICS format, so ...), but iCal allows you to update published
>> calendar on every changes, so this is doing what you want, no ?
>
> Now Outlook has the possibility to import *.ics calendars as a  
> whole, after
> downloading it OR to open one (generated on the fly) within Outlook  
> and save
> it, etc.
> Also Outlook has the possibility to send an opened event to send as  
> a *.ics.
> (top-menu: Actions -> Send as *.ics). It than contains all the  
> necessary
> data (uid, timezones, whatever). With iCal one can do exactly the  
> same.
>
> Given the above, the suggested (and working!!) solution is not only  
> fast and
> efficient, it's also phpicalendar-updating for dummy's. For anyone  
> who's
> able to use its calendar and emailprogramm, can than update a calendar
> (s)he's authorized to, by email-recognition.
> Again, it was very very simple.
>
>> The first goal of this project is to publish calendars on a network.
>> I agree that something interesting would be to add is a way to edit
>> calendars. Various hacks had been done on this subject, and
>> particularly something to send an email to the calendar owner to book
>> time.
> This sounds like the alternative 1., which requires an administrators
> interaction. I hope I now explained well enough that my suggestion is
> without any human interaction and yet with very limited programming.
>
> Of course than also deleting had to be added, and I did.
> Doing so also save item to outlook resp. save item to iCal was  
> easily made.
>
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel