phpicalendar-devel — Mailing list for PHP iCalendar Developers

Re: [PHPiCalendar-DEV] Session support

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

If we did something like this how far out would we want the first parse 
to be? My initial though would then be for the entire year to cover 
enough ground. The parser is still pretty quick but the more options we 
add will start to load it down. What about a recurring array, since 
recurring events have same start, end, description, and summary, all 
we'd need to store is the dates it happened. Maybe we'd have to  look 
at 2 arrays.

-C

On Friday, October 4, 2002, at 10:08  AM, Jared wrote:

> Hmm, interesting idea. I like it better than sessions. The only reason 
> we want sessions right now is to store the processed cals. If the 
> calendar is already processed, the next users can use that as well. I 
> like it.
>
> Chad?
>
> -Jared
>
> BTW, my AIM just went down for some odd reason, so I'm not online.
>
> On Friday, October 4, 2002, at 12:05  PM, Matt Jarjoura wrote:
>
>> On 10/4/02 12:54 PM, "Jared" <xe...@si...> wrote:
>>
>>> On Friday, October 4, 2002, at 11:44  AM, Chad wrote:
>>>
>>>> Ok, so I want to talk about Sessions.... how are we going to speed 
>>>> up
>>>> and lighten processor load for 0.6 PHP iCalendar? :-)
>>>
>>> Well, I think if we write all the main variables to a session along
>>> with the filemtime() of the last parsed file, it can check each page
>>> load whether the file is different and if not, use the session data. 
>>> If
>>> it is different, parse the file again and write it to the session. I
>>> don't think it's too complicated, really. We just need $master_array,
>>> $getdate, $cal, and $cal_modDate. I don't know if we need anything 
>>> else
>>> (at least, I can't think of it off the top of my head).
>>>
>>> -Jared
>>>
>>
>>
>> In that case, I would store all the variables inside on array and run 
>> the
>> "serialize()" function and save the serialized data to a file with 
>> the same
>> file date and time as the original ical file.  Then it would be easy 
>> to
>> check the date of the "compiled" code to the ical file.  If the same, 
>> just
>> "unseralize()" the array back into php, and no processing is 
>> required.  This
>> way if you have 10 new users in a second, it won't kill the CPU.  Cuz 
>> a new
>> session will be created per user per browser.  10 new users with a 
>> session
>> will process the original ical file 10 times.  ;-)
>>
>> ==========================
>>         Matt Jarjoura
>> ==========================
>> |  UMBC  | Phi-Delta 313 |
>> ==========================
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>
>
>
>
> -------------------------------------------------------
> 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] Session support

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

I just thought of something else. Right now, the processed calendar 
would only have a range of 3 months. This month, last month, and next 
month. If someone is looking at last month, they don't need to know 
next month but rather, two months before that. So it would be very 
common for two people to not be looking at the same set of required 
data as the next.

This could be extended out further, if needed, to any range of time. I 
don't know what is acceptable or if sessions truly are the best way to 
go.

-Jared

On Friday, October 4, 2002, at 12:08  PM, Jared wrote:

> Hmm, interesting idea. I like it better than sessions. The only reason 
> we want sessions right now is to store the processed cals. If the 
> calendar is already processed, the next users can use that as well. I 
> like it.
>
> Chad?
>
> -Jared
>
> BTW, my AIM just went down for some odd reason, so I'm not online.
>
> On Friday, October 4, 2002, at 12:05  PM, Matt Jarjoura wrote:
>
>> On 10/4/02 12:54 PM, "Jared" <xe...@si...> wrote:
>>
>>> On Friday, October 4, 2002, at 11:44  AM, Chad wrote:
>>>
>>>> Ok, so I want to talk about Sessions.... how are we going to speed 
>>>> up
>>>> and lighten processor load for 0.6 PHP iCalendar? :-)
>>>
>>> Well, I think if we write all the main variables to a session along
>>> with the filemtime() of the last parsed file, it can check each page
>>> load whether the file is different and if not, use the session data. 
>>> If
>>> it is different, parse the file again and write it to the session. I
>>> don't think it's too complicated, really. We just need $master_array,
>>> $getdate, $cal, and $cal_modDate. I don't know if we need anything 
>>> else
>>> (at least, I can't think of it off the top of my head).
>>>
>>> -Jared
>>>
>>
>>
>> In that case, I would store all the variables inside on array and run 
>> the
>> "serialize()" function and save the serialized data to a file with 
>> the same
>> file date and time as the original ical file.  Then it would be easy 
>> to
>> check the date of the "compiled" code to the ical file.  If the same, 
>> just
>> "unseralize()" the array back into php, and no processing is 
>> required.  This
>> way if you have 10 new users in a second, it won't kill the CPU.  Cuz 
>> a new
>> session will be created per user per browser.  10 new users with a 
>> session
>> will process the original ical file 10 times.  ;-)
>>
>> ==========================
>>         Matt Jarjoura
>> ==========================
>> |  UMBC  | Phi-Delta 313 |
>> ==========================
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>
>
>
>
> -------------------------------------------------------
> 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] Session support

[<ev...@ly...>]

Session handling are built-in to PHP, and has been for some time now.
The server stores the users session variables in /tmp/sess_xxx (where=20
xxx is the session_id).

On fredag, okt 4, 2002, at 19:05 Europe/Oslo, Marook Zuug Kenja wrote:

> Hi All.
>
> On fredag, okt 4, 2002, at 18:54 Europe/Copenhagen, Jared wrote:
>
>>> Ok, so I want to talk about Sessions.... how are we going to speed=20=

>>> up and lighten processor load for 0.6 PHP iCalendar? :-)
>>
>> Well, I think if we write all the main variables to a session along=20=

>> with the filemtime() of the last parsed file, it can check each page=20=

>> load whether the file is different and if not, use the session data.=20=

>> If it is different, parse the file again and write it to the session.=20=

>> I don't think it's too complicated, really. We just need=20
>> $master_array, $getdate, $cal, and $cal_modDate. I don't know if we=20=

>> need anything else (at least, I can't think of it off the top of my=20=

>> head).
>
> So, I'm new to session handling in PHP, though I have been doing some=20=

> with MySQL.
> Does PHP have build-in session-handling? With cashing of data?
>
> 	Jakob Peterh=E4nsel
>
> "Tell me why, don't we try, not to break our hearts
>   and make it so hard for our selfs"
> P.S.B. 1987
>
> Email: ja...@hj...
> AIM: Marook

Re: [PHPiCalendar-DEV] Session support

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

Hmm, interesting idea. I like it better than sessions. The only reason 
we want sessions right now is to store the processed cals. If the 
calendar is already processed, the next users can use that as well. I 
like it.

Chad?

-Jared

BTW, my AIM just went down for some odd reason, so I'm not online.

On Friday, October 4, 2002, at 12:05  PM, Matt Jarjoura wrote:

> On 10/4/02 12:54 PM, "Jared" <xe...@si...> wrote:
>
>> On Friday, October 4, 2002, at 11:44  AM, Chad wrote:
>>
>>> Ok, so I want to talk about Sessions.... how are we going to speed up
>>> and lighten processor load for 0.6 PHP iCalendar? :-)
>>
>> Well, I think if we write all the main variables to a session along
>> with the filemtime() of the last parsed file, it can check each page
>> load whether the file is different and if not, use the session data. 
>> If
>> it is different, parse the file again and write it to the session. I
>> don't think it's too complicated, really. We just need $master_array,
>> $getdate, $cal, and $cal_modDate. I don't know if we need anything 
>> else
>> (at least, I can't think of it off the top of my head).
>>
>> -Jared
>>
>
>
> In that case, I would store all the variables inside on array and run 
> the
> "serialize()" function and save the serialized data to a file with the 
> same
> file date and time as the original ical file.  Then it would be easy to
> check the date of the "compiled" code to the ical file.  If the same, 
> just
> "unseralize()" the array back into php, and no processing is required. 
>  This
> way if you have 10 new users in a second, it won't kill the CPU.  Cuz 
> a new
> session will be created per user per browser.  10 new users with a 
> session
> will process the original ical file 10 times.  ;-)
>
> ==========================
>         Matt Jarjoura
> ==========================
> |  UMBC  | Phi-Delta 313 |
> ==========================
>
>
>
>
> -------------------------------------------------------
> 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] File or DB driven? Or both?

[<ev...@ly...>]

When it comes to theme support, many users will not be satisfied with=20
the option to only change the css.
With Smarty, the end-users don't need to know any php coding at all.=20
They just have to keep in mind how they work.
PhpBB uses the same kind of template system (though they have developed=20=

their own before Smarty was availiable).
Adding support for true themes doesn't mean that you can't offer the=20
same theme support as you thought of (just css configuration).
One can combine these two. Basicly PHPiCalendar would be something a=20
lot of web-developers are looking for to integrate with other services=20=

they may have, and then there is always a demand for the support for=20
themes.

When it comes to the session thing, it shouldn't be a big problem=20
really.
One idea would be to make the iCal parser to create an object=20
reflecting the iCalendar's, and storing that object to a session=20
variable.

- Even Andr=E9

On fredag, okt 4, 2002, at 18:44 Europe/Oslo, Chad wrote:
So before everyone gets all excited about maybe making a calendar
groupware program, let me just go and say while its interesting and
possible to work on as a MOD, I don't want it being in the core of th
project. The program is meant as a displayer only, and one that is easy
enough that even Mac users (yes, I am) can just upload and run with
little / no config. You also don't want users modifying their iCals on
the web and wondering why at home its not showing up in their iCal
program.

Now working on a groupware Calendar and going after WebCalendar or
Kronolith is an enticing idea, one that I think we could support as a
MOD offshoot (or Plugin) of the Project. Right now though we are at
least a month away from 1.0, and there are many aspects of the iCal,
vCal, xCal file we don't support. First off it would be nice to
recognize and parse / display all three. Secondly we barely support the
core of the iCal spec, and need to cover things like alarms, attendees,
todos... And most importantly we'd be already duplicating the fine work
of Mozilla and iCal. I barely use iCal as it is, heh.

Smarty looks interesting, but most of the work on Themes is already
finished. Once again ease of use is a factor. Simple changes to the css
file and new graphics and the theme is built, no PHP skittles needed.
Though I will give Smarty another look today to be fair. Trust me this
brainstorming is good, so feel free to keep bringing up these issues,
we just have releases to be working on too.

Ok, so I want to talk about Sessions.... how are we going to speed up
and lighten processor load for 0.6 PHP iCalendar? :-)

What i envision PHP iCalendar becoming is similar to phpBB. Themable,
Modable, good looking, and popular!

Cheers,
Chad

Re: [PHPiCalendar-DEV] Session support

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

Hi All.

On fredag, okt 4, 2002, at 18:54 Europe/Copenhagen, Jared wrote:

>> Ok, so I want to talk about Sessions.... how are we going to speed up=20=

>> and lighten processor load for 0.6 PHP iCalendar? :-)
>
> Well, I think if we write all the main variables to a session along=20
> with the filemtime() of the last parsed file, it can check each page=20=

> load whether the file is different and if not, use the session data.=20=

> If it is different, parse the file again and write it to the session.=20=

> I don't think it's too complicated, really. We just need=20
> $master_array, $getdate, $cal, and $cal_modDate. I don't know if we=20
> need anything else (at least, I can't think of it off the top of my=20
> head).

So, I'm new to session handling in PHP, though I have been doing some=20
with MySQL.
Does PHP have build-in session-handling? With cashing of data?

	Jakob Peterh=E4nsel

"Tell me why, don't we try, not to break our hearts
   and make it so hard for our selfs"
P.S.B. 1987

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

Re: [PHPiCalendar-DEV] Session support

[Matt J. <mj...@um...>]

On 10/4/02 12:54 PM, "Jared" <xe...@si...> wrote:

> On Friday, October 4, 2002, at 11:44  AM, Chad wrote:
> 
>> Ok, so I want to talk about Sessions.... how are we going to speed up
>> and lighten processor load for 0.6 PHP iCalendar? :-)
> 
> Well, I think if we write all the main variables to a session along
> with the filemtime() of the last parsed file, it can check each page
> load whether the file is different and if not, use the session data. If
> it is different, parse the file again and write it to the session. I
> don't think it's too complicated, really. We just need $master_array,
> $getdate, $cal, and $cal_modDate. I don't know if we need anything else
> (at least, I can't think of it off the top of my head).
> 
> -Jared
> 


In that case, I would store all the variables inside on array and run the
"serialize()" function and save the serialized data to a file with the same
file date and time as the original ical file.  Then it would be easy to
check the date of the "compiled" code to the ical file.  If the same, just
"unseralize()" the array back into php, and no processing is required.  This
way if you have 10 new users in a second, it won't kill the CPU.  Cuz a new
session will be created per user per browser.  10 new users with a session
will process the original ical file 10 times.  ;-)

==========================
        Matt Jarjoura
==========================
|  UMBC  | Phi-Delta 313 |
==========================

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

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

Yes, sessions  would temporarily store the processed calendar so it 
doesn't need to parse on every page load.

My AIM is Jawful. Feel free to contact me. I'd have an open PHP 
iCalendar chat but apparently those don't work from AIM to .Mac and 
back.

-Jared

On Friday, October 4, 2002, at 12:01  PM, Matt Jarjoura wrote:

>
>> Ok, so I want to talk about Sessions.... how are we going to speed up
>> and lighten processor load for 0.6 PHP iCalendar? :-)
>>
>> What i envision PHP iCalendar becoming is similar to phpBB. Themable,
>> Modable, good looking, and popular!
>
> Themes are easy as pie, I have some code directly from phpBB that in 2 
> lines
> of code does themes.  If you plan on supporting them, do it from the 
> start
> however, cuz later on you'll have to do a lot of rewriting.
>
> 2nd, what exactly do you want sessions to provide for you?  To store 
> the
> processed calendar code?
>
> 3rd... Do you have AIM or IRC?
>
>
>
> ==========================
>         Matt Jarjoura
> ==========================
> |  UMBC  | Phi-Delta 313 |
> ==========================
>
>
>
>
> -------------------------------------------------------
> 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] File or DB driven? Or both?

[Matt J. <mj...@um...>]

 
> Ok, so I want to talk about Sessions.... how are we going to speed up
> and lighten processor load for 0.6 PHP iCalendar? :-)
> 
> What i envision PHP iCalendar becoming is similar to phpBB. Themable,
> Modable, good looking, and popular!

Themes are easy as pie, I have some code directly from phpBB that in 2 lines
of code does themes.  If you plan on supporting them, do it from the start
however, cuz later on you'll have to do a lot of rewriting.

2nd, what exactly do you want sessions to provide for you?  To store the
processed calendar code?

3rd... Do you have AIM or IRC?



==========================
        Matt Jarjoura
==========================
|  UMBC  | Phi-Delta 313 |
==========================

[PHPiCalendar-DEV] Session support

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

On Friday, October 4, 2002, at 11:44  AM, Chad wrote:

> Ok, so I want to talk about Sessions.... how are we going to speed up 
> and lighten processor load for 0.6 PHP iCalendar? :-)

Well, I think if we write all the main variables to a session along 
with the filemtime() of the last parsed file, it can check each page 
load whether the file is different and if not, use the session data. If 
it is different, parse the file again and write it to the session. I 
don't think it's too complicated, really. We just need $master_array, 
$getdate, $cal, and $cal_modDate. I don't know if we need anything else 
(at least, I can't think of it off the top of my head).

-Jared

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

[<ev...@ly...>]

The thing is that we'll probably have to (saying this without knowing=20
at all the module-functionality of XOOPS) develop the code with respect=20=

to three different scenarios. If we have this in mind while structuring=20=

the code layout, it shouldn't be that hard to do this.
This would allow us to easily support other projects similar to XOOPS=20
as well.

- Even Andr=E9

On fredag, okt 4, 2002, at 17:54 Europe/Oslo, Jakob Peterh=E4nsel wrote:

> Hi..
>
>
> On fredag, okt 4, 2002, at 17:41 Europe/Copenhagen, Even Andr=E9 =
Fiskvik=20
> wrote:
>
>> Ok, I think I'm getting your picture regarding XOOPS now.
>> You are seeing XOOPS managing all of the user administration and user=20=

>> management?
>> This would limit the users of the phpicalendar, because if they=20
>> really wanted to use a db, they would have to have XOOPS to use it,
>> wouldn't that be a bad idea?
>
> Actually, I was more thinking about XOOPS as an option. I use it on=20
> some of my sites, and IF it would be enabled as a module in XOOPS (a=20=

> long with being standalone!), using the same userdb as XOOPS would be=20=

> natural. It could also be a possible solution to use both PHP iCal &=20=

> XOOPS users... who knows..
>
>> As for theme management, this is an easy thing to do ourselves.=20
>> Smarty (smarty.php.net) is a fine class for doing oop "theming".
>
> Smarty is what XOOPS is moving to, in the next major release, so=20
> Smarty theme support would be natural, and might be the cool way to > =
go.
>
>> I wouldn't want to limit the users to just use MySQL either, with the=20=

>> DB class from PEAR (pear.php.net), you can use almost any database=20
>> you like.
>> I have myself the possibility of testing at least MySQL, PostgreSQL=20=

>> and Oracle.
>
> Sure! MySQL was just a suggestion.
>
>> Of course, using XOOPS would help us in that way that we wouldn't=20
>> have to write the code for user management ourselves.
>> I don't see any further benefits from using XOOPS, but please correct=20=

>> me if I'm wrong..
>
> You are right in Getting benefits. I would just like to use this as a=20=

> module in XOOPS in the future, if possible. Giving XOOPS the benefits=20=

> of PHP iCal.
>
> 	Jakob Peterh=E4nsel
>
> "Tell me why, don't we try, not to break our hearts
>   and make it so hard for our selfs"
> P.S.B. 1987
>
> Email: ja...@hj...
> AIM: Marook
>

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

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

So before everyone gets all excited about maybe making a calendar=20
groupware program, let me just go and say while its interesting and=20
possible to work on as a MOD, I don't want it being in the core of th=20
project. The program is meant as a displayer only, and one that is easy=20=

enough that even Mac users (yes, I am) can just upload and run with=20
little / no config. You also don't want users modifying their iCals on=20=

the web and wondering why at home its not showing up in their iCal=20
program.

Now working on a groupware Calendar and going after WebCalendar or=20
Kronolith is an enticing idea, one that I think we could support as a=20
MOD offshoot (or Plugin) of the Project. Right now though we are at=20
least a month away from 1.0, and there are many aspects of the iCal,=20
vCal, xCal file we don't support. First off it would be nice to=20
recognize and parse / display all three. Secondly we barely support the=20=

core of the iCal spec, and need to cover things like alarms, attendees,=20=

todos... And most importantly we'd be already duplicating the fine work=20=

of Mozilla and iCal. I barely use iCal as it is, heh.

Smarty looks interesting, but most of the work on Themes is already=20
finished. Once again ease of use is a factor. Simple changes to the css=20=

file and new graphics and the theme is built, no PHP skittles needed.=20
Though I will give Smarty another look today to be fair. Trust me this=20=

brainstorming is good, so feel free to keep bringing up these issues,=20
we just have releases to be working on too.

Ok, so I want to talk about Sessions.... how are we going to speed up=20
and lighten processor load for 0.6 PHP iCalendar? :-)

What i envision PHP iCalendar becoming is similar to phpBB. Themable,=20
Modable, good looking, and popular!

Cheers,
Chad


On Friday, October 4, 2002, at 08:54 AM, Jared wrote:

> Yes, if the end-user would need XOOPS already installed, then it=20
> really isn't an option. We don't even want to require they have a=20
> database, let alone a specific CMS. Does that apply to Smarty or PEAR?=20=

> If we choose to use either of those classes, will the end-user be=20
> required to have anything special (or will a minimum version of PHP be=20=

> enough?)
>
> -Jared
>
> On Friday, October 4, 2002, at 10:41  AM, Even Andr=E9 Fiskvik wrote:
>
>> Ok, I think I'm getting your picture regarding XOOPS now.
>> You are seeing XOOPS managing all of the user administration and user=20=

>> management?
>> This would limit the users of the phpicalendar, because if they=20
>> really wanted to use a db, they would have to have XOOPS to use it,
>> wouldn't that be a bad idea?
>> As for theme management, this is an easy thing to do ourselves.=20
>> Smarty (smarty.php.net) is a fine class for doing oop "theming".
>> I wouldn't want to limit the users to just use MySQL either, with the=20=

>> DB class from PEAR (pear.php.net), you can use almost any database=20
>> you like.
>> I have myself the possibility of testing at least MySQL, PostgreSQL=20=

>> and Oracle.
>>
>> Of course, using XOOPS would help us in that way that we wouldn't=20
>> have to write the code for user management ourselves.
>> I don't see any further benefits from using XOOPS, but please correct=20=

>> me if I'm wrong...
>>
>> Even Andr=E9 Fiskvik
>>
>> On fredag, okt 4, 2002, at 16:49 Europe/Oslo, Marook Zuug Kenja =
wrote:
>>
>>> Hi All.
>>>
>>> Ok, I agree that the initial setup of PHP iCalendar should be=20
>>> filebased. Basically, if files exist in the 'calendar' dir, show=20
>>> them like it's done now. No challenge there.
>>>
>>> The option, should be to enable database driven calendars.
>>> Options for this, include a calendar submitted via FTP/HTTP/WebDAV=20=

>>> to the server. A calendar submitted this way, could be read-only in=20=

>>> the database, unless a new 'upload' is submitted.
>>>
>>> Now, subscribing to calendars in the database, could be mush more=20
>>> dynamic, than file based ones, since we can pass parameters to php=20=

>>> that performs searches and maybe even date-range selections. The=20
>>> options are many, and I agree that we need to focus on main issues,=20=

>>> but a move to a db would allow large-scale sites to support many=20
>>> users.
>>>
>>> The admin-via-web aspect of a db driven calendar, would also make a=20=

>>> move towards enabling non-Mac/iCal users to maintain the calendar,=20=

>>> and make them available to Mac/iCal users 'the cool way'.
>>>
>>> And we don't need to generate files from the db, just a data-stream=20=

>>> when asked for it.
>>>
>>> I haven't looked into how iCal askes for changes (HEAD request ->=20
>>> date changed-> download .ics..) or it simply downloads the files at=20=

>>> specified times. But having a LAST_CHANGED date field for the=20
>>> calendar would make this trivial.
>>>
>>> Regarding XOOPS, yes this would make PHP iCal a module to XOOPS. I=20=

>>> don't know how much work this takes, but I assume it's mostly User &=20=

>>> Admin integration. XOOPS is also PHP/MySQL so should be possible.=20
>>> Maybe a branche?
>>> I know XOOPS uses themes. I has User integration and web-based=20
>>> admin/preference setup. All things PHP iCal needs, or has requests=20=

>>> to get.
>>>
>>> Looking fwd to get my iBook back from repair, so I can dig into=20
>>> this... (Note, don't drop them on the floor from 2m. height...)
>>>
>>>
>>> 	Jakob Peterh=E4nsel
>>>
>>> "A kiss is the proof, that the best in life, is found right under=20
>>> your nose"
>>> Billie Jean Blanton
>>>
>>> Email: ja...@hj...
>>> AIM: Marook=

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

[<ja...@hj...>]

Hi..


On fredag, okt 4, 2002, at 17:41 Europe/Copenhagen, Even Andr=E9 Fiskvik=20=

wrote:

> Ok, I think I'm getting your picture regarding XOOPS now.
> You are seeing XOOPS managing all of the user administration and user=20=

> management?
> This would limit the users of the phpicalendar, because if they really=20=

> wanted to use a db, they would have to have XOOPS to use it,
> wouldn't that be a bad idea?

Actually, I was more thinking about XOOPS as an option. I use it on=20
some of my sites, and IF it would be enabled as a module in XOOPS (a=20
long with being standalone!), using the same userdb as XOOPS would be=20
natural. It could also be a possible solution to use both PHP iCal &=20
XOOPS users... who knows..

> As for theme management, this is an easy thing to do ourselves. Smarty=20=

> (smarty.php.net) is a fine class for doing oop "theming".

Smarty is what XOOPS is moving to, in the next major release, so Smarty=20=

theme support would be natural, and might be the cool way to go.

> I wouldn't want to limit the users to just use MySQL either, with the=20=

> DB class from PEAR (pear.php.net), you can use almost any database you=20=

> like.
> I have myself the possibility of testing at least MySQL, PostgreSQL=20
> and Oracle.

Sure! MySQL was just a suggestion.

> Of course, using XOOPS would help us in that way that we wouldn't have=20=

> to write the code for user management ourselves.
> I don't see any further benefits from using XOOPS, but please correct=20=

> me if I'm wrong..

You are right in Getting benefits. I would just like to use this as a=20
module in XOOPS in the future, if possible. Giving XOOPS the benefits=20
of PHP iCal.

	Jakob Peterh=E4nsel

"Tell me why, don't we try, not to break our hearts
   and make it so hard for our selfs"
P.S.B. 1987

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

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

[<ev...@ly...>]

Smarty is just a LGPL php class that can be included in the=20
distribution of phpicalendar.
It requires PHP 4.0.6 or later. So it only boils down to PHP version on=20=

this one.
As for PEAR it is automaticly installed in all newer releases of PHP,=20
and the include path
is set to use this as well (so if you just use require('DB.php'); it=20
will use the one from the PEAR distribution).
I'm not sure what version of PHP started including PEAR in it's=20
distribution, but this is not a problem either. The PEAR DB classes can=20=

be located in the inc/ directory, and if PHP can't find that PEAR is=20
installed, it just uses the files from the include directory.
I'm also not sure about what version of PHP PEAR requires.

The end point, there are no requirements for the user other than the=20
version of PHP when using these frameworks.

- Even Andr=E9

On fredag, okt 4, 2002, at 17:54 Europe/Oslo, Jared wrote:

Yes, if the end-user would need XOOPS already installed, then it really
isn't an option. We don't even want to require they have a database,
let alone a specific CMS. Does that apply to Smarty or PEAR? If we
choose to use either of those classes, will the end-user be required to
have anything special (or will a minimum version of PHP be enough?)

-Jared=20=

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

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

Yes, if the end-user would need XOOPS already installed, then it really=20=

isn't an option. We don't even want to require they have a database,=20
let alone a specific CMS. Does that apply to Smarty or PEAR? If we=20
choose to use either of those classes, will the end-user be required to=20=

have anything special (or will a minimum version of PHP be enough?)

-Jared

On Friday, October 4, 2002, at 10:41  AM, Even Andr=E9 Fiskvik wrote:

> Ok, I think I'm getting your picture regarding XOOPS now.
> You are seeing XOOPS managing all of the user administration and user=20=

> management?
> This would limit the users of the phpicalendar, because if they really=20=

> wanted to use a db, they would have to have XOOPS to use it,
> wouldn't that be a bad idea?
> As for theme management, this is an easy thing to do ourselves. Smarty=20=

> (smarty.php.net) is a fine class for doing oop "theming".
> I wouldn't want to limit the users to just use MySQL either, with the=20=

> DB class from PEAR (pear.php.net), you can use almost any database you=20=

> like.
> I have myself the possibility of testing at least MySQL, PostgreSQL=20
> and Oracle.
>
> Of course, using XOOPS would help us in that way that we wouldn't have=20=

> to write the code for user management ourselves.
> I don't see any further benefits from using XOOPS, but please correct=20=

> me if I'm wrong...
>
> Even Andr=E9 Fiskvik
>
> On fredag, okt 4, 2002, at 16:49 Europe/Oslo, Marook Zuug Kenja wrote:
>
>> Hi All.
>>
>> Ok, I agree that the initial setup of PHP iCalendar should be=20
>> filebased. Basically, if files exist in the 'calendar' dir, show them=20=

>> like it's done now. No challenge there.
>>
>> The option, should be to enable database driven calendars.
>> Options for this, include a calendar submitted via FTP/HTTP/WebDAV to=20=

>> the server. A calendar submitted this way, could be read-only in the=20=

>> database, unless a new 'upload' is submitted.
>>
>> Now, subscribing to calendars in the database, could be mush more=20
>> dynamic, than file based ones, since we can pass parameters to php=20
>> that performs searches and maybe even date-range selections. The=20
>> options are many, and I agree that we need to focus on main issues,=20=

>> but a move to a db would allow large-scale sites to support many=20
>> users.
>>
>> The admin-via-web aspect of a db driven calendar, would also make a=20=

>> move towards enabling non-Mac/iCal users to maintain the calendar,=20
>> and make them available to Mac/iCal users 'the cool way'.
>>
>> And we don't need to generate files from the db, just a data-stream=20=

>> when asked for it.
>>
>> I haven't looked into how iCal askes for changes (HEAD request ->=20
>> date changed-> download .ics..) or it simply downloads the files at=20=

>> specified times. But having a LAST_CHANGED date field for the=20
>> calendar would make this trivial.
>>
>> Regarding XOOPS, yes this would make PHP iCal a module to XOOPS. I=20
>> don't know how much work this takes, but I assume it's mostly User &=20=

>> Admin integration. XOOPS is also PHP/MySQL so should be possible.=20
>> Maybe a branche?
>> I know XOOPS uses themes. I has User integration and web-based=20
>> admin/preference setup. All things PHP iCal needs, or has requests to=20=

>> get.
>>
>> Looking fwd to get my iBook back from repair, so I can dig into=20
>> this... (Note, don't drop them on the floor from 2m. height...)
>>
>>
>> 	Jakob Peterh=E4nsel
>>
>> "A kiss is the proof, that the best in life, is found right under=20
>> your nose"
>> Billie Jean Blanton
>>
>> Email: ja...@hj...
>> AIM: Marook=

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

[<ev...@ly...>]

Ok, I think I'm getting your picture regarding XOOPS now.
You are seeing XOOPS managing all of the user administration and user=20
management?
This would limit the users of the phpicalendar, because if they really=20=

wanted to use a db, they would have to have XOOPS to use it,
wouldn't that be a bad idea?
As for theme management, this is an easy thing to do ourselves. Smarty=20=

(smarty.php.net) is a fine class for doing oop "theming".
I wouldn't want to limit the users to just use MySQL either, with the=20
DB class from PEAR (pear.php.net), you can use almost any database you=20=

like.
I have myself the possibility of testing at least MySQL, PostgreSQL and=20=

Oracle.

Of course, using XOOPS would help us in that way that we wouldn't have=20=

to write the code for user management ourselves.
I don't see any further benefits from using XOOPS, but please correct=20
me if I'm wrong...

Even Andr=E9 Fiskvik

On fredag, okt 4, 2002, at 16:49 Europe/Oslo, Marook Zuug Kenja wrote:

> Hi All.
>
> Ok, I agree that the initial setup of PHP iCalendar should be=20
> filebased. Basically, if files exist in the 'calendar' dir, show them=20=

> like it's done now. No challenge there.
>
> The option, should be to enable database driven calendars.
> Options for this, include a calendar submitted via FTP/HTTP/WebDAV to=20=

> the server. A calendar submitted this way, could be read-only in the=20=

> database, unless a new 'upload' is submitted.
>
> Now, subscribing to calendars in the database, could be mush more=20
> dynamic, than file based ones, since we can pass parameters to php=20
> that performs searches and maybe even date-range selections. The=20
> options are many, and I agree that we need to focus on main issues,=20
> but a move to a db would allow large-scale sites to support many > =
users.
>
> The admin-via-web aspect of a db driven calendar, would also make a=20
> move towards enabling non-Mac/iCal users to maintain the calendar, and=20=

> make them available to Mac/iCal users 'the cool way'.
>
> And we don't need to generate files from the db, just a data-stream=20
> when asked for it.
>
> I haven't looked into how iCal askes for changes (HEAD request -> date=20=

> changed-> download .ics..) or it simply downloads the files at=20
> specified times. But having a LAST_CHANGED date field for the calendar=20=

> would make this trivial.
>
> Regarding XOOPS, yes this would make PHP iCal a module to XOOPS. I=20
> don't know how much work this takes, but I assume it's mostly User &=20=

> Admin integration. XOOPS is also PHP/MySQL so should be possible.=20
> Maybe a branche?
> I know XOOPS uses themes. I has User integration and web-based=20
> admin/preference setup. All things PHP iCal needs, or has requests to=20=

> get.
>
> Looking fwd to get my iBook back from repair, so I can dig into=20
> this... (Note, don't drop them on the floor from 2m. height...)
>
>
> 	Jakob Peterh=E4nsel
>
> "A kiss is the proof, that the best in life, is found right under your=20=

> nose"
> Billie Jean Blanton
>
> Email: ja...@hj...
> AIM: Marook=

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

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

Hi All.

Ok, I agree that the initial setup of PHP iCalendar should be=20
filebased. Basically, if files exist in the 'calendar' dir, show them=20
like it's done now. No challenge there.

The option, should be to enable database driven calendars.
Options for this, include a calendar submitted via FTP/HTTP/WebDAV to=20
the server. A calendar submitted this way, could be read-only in the=20
database, unless a new 'upload' is submitted.

Now, subscribing to calendars in the database, could be mush more=20
dynamic, than file based ones, since we can pass parameters to php that=20=

performs searches and maybe even date-range selections. The options are=20=

many, and I agree that we need to focus on main issues, but a move to a=20=

db would allow large-scale sites to support many users.

The admin-via-web aspect of a db driven calendar, would also make a=20
move towards enabling non-Mac/iCal users to maintain the calendar, and=20=

make them available to Mac/iCal users 'the cool way'.

And we don't need to generate files from the db, just a data-stream=20
when asked for it.

I haven't looked into how iCal askes for changes (HEAD request -> date=20=

changed-> download .ics..) or it simply downloads the files at=20
specified times. But having a LAST_CHANGED date field for the calendar=20=

would make this trivial.

Regarding XOOPS, yes this would make PHP iCal a module to XOOPS. I=20
don't know how much work this takes, but I assume it's mostly User &=20
Admin integration. XOOPS is also PHP/MySQL so should be possible. Maybe=20=

a branche?
I know XOOPS uses themes. I has User integration and web-based=20
admin/preference setup. All things PHP iCal needs, or has requests to=20
get.

Looking fwd to get my iBook back from repair, so I can dig into this...=20=

(Note, don't drop them on the floor from 2m. height...)


	Jakob Peterh=E4nsel

"A kiss is the proof, that the best in life, is found right under your=20=

nose"
Billie Jean Blanton

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

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

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

I can see being able to take the parsed iCal and put it into a =20
database. A simple filemtime() check would tell us whether we need to =20=

reparse or if we can get the data from the database. However, I don't =20=

want that to be the only solution. I think if we had an option for =20
database setup, it could make it much faster and much easier on those =20=

running PHP iCalendar websites for many users. However, we need to =20
leave it flat-file based by default so the people who run it from there =20=

Sites directory don't have to know about, or think about, what MySQL is =20=

and how to install it/set it up. Implementing a database option might =20=

be something to look forward to, possibly before 1.0.

I think for editing and creating calendars, a database would be crucial =20=

as working with flat files would become a pain very quickly. That would =20=

be the choice of the end user. They get a basic =20
view-your-iCals-in-your-browser solution with no configuration, and a =20=

more advanced create-edit-and-view solution if they choose to set up a =20=

database.

Personally, I would love for the iCal to be parsed into a database so I =20=

know it's not being parsed every time. I know what goes into parsing! :)

Sessions can, and will, help keep the amount of parsing down for the =20
regular user. I believe this needs to be implemented one way or the =20
other. However, being database compatible, it offers a lot more options.

I have no clue what XOOPS is so I'm off to Google. ;)

-Jared


On Friday, October 4, 2002, at 08:09  AM, Even Andr=E9 Fiskvik wrote:

> I also thought about extending the phpicalendar software to have many =20=

> of these features, and your points are very good.
> The drawback of the database method is that it would probably require =20=

> someone with good cocoa skills to program either a plug-in for iCal
> (the prefered way), og an application that publish the calendars for =20=

> you.
>
> This system can go as big as it wants, and the problem is setting the =20=

> requirements and the limits for it as well.
> What functions should the system have? Should it be able to server =20
> hundreds of users, from different companies/groups etc.
> Or should each company/group have their own setup?
>
> But it would for sure be ahead of others, and a major feature to =20
> support editing/creating/deleting new events from the web.
> If we want such a feature, then we would also have to make it =20
> user-based for sure. I'm more into that db thing then, than making it =20=

> all flat-file.
>
> On fredag, okt 4, 2002, at 13:38 Europe/Oslo, Marook Zuug Kenja wrote:
>
>> So, we have a framework for displaying iCal files in a webbrowser.
>> It's cool, and makes things a lot easier, makes co-workers access =20
>> info from everywhere.
>>
>> I would like to take this further. I would like to give options, and =20=

>> most of all, I would like to make this work the other way round, =20
>> managing the calendar via the browser, and subscribe to it (or parts =20=

>> of if!) via app's like iCal.
>>
>> Aspects of the file method:
>> - Easy publishing from app's like iCal.
>> - No need to set up a Database
>>
>> Aspects of a database method:
>> - Possibility to edit info from the web, without re-writing files.
>> - Multiuser features
>> - Integration with XOOPS (http://www.xoops.org)
>> - Subscribe to parts of a calendar (could be done with files, but =20
>> might be harder)
>> - Might be able to support larger numbers of users/calendars.
>>
>>
>> Would it be feasible to be able to create calendars via the web?
>> Should it be done in a database?
>>
>> If we would like to make it user-based, I think we need to move the =20=

>> data to a database, as the iCal file format does not support =20
>> user-designation and/or restrictions.
>> I see no problem in parsing an iCal file submitted via a Form upload, =
=20
>> and putting it in a MySQL db. Once there, it can be searched, shown, =20=

>> and send via all forms of protocols. It would make it possible to =20
>> subscribe to parts of the calendar, if needed.
>>
>> One usage for this could be, like this:
>> You work in a department with shifting hours, and the manager makes =20=

>> the work-shift-plan. You would like to subscribe to this calendar, =20=

>> but the one you sync to your Palm/iPod/phome, should only be the =20
>> hours you work.
>> - simple
>> Subscribe to =20
>> webcal://your.server.com/phpical/=20
>> subscribe.php?ical=3Dworkshifts&subject=3DJoe Black
>>
>> Get the idea?
>>
>> I know this is not a 1.0 thing, but we could start to work with his =20=

>> in mind.
>> I would love to give a hand...
>>
>>
>> Marook Zuug Kenja
>>
>> [  MIB  ]
>>
>> 	Jakob Peterh=E4nsel
>>
>> "Tell me why, don't we try, not to break our hearts
>>   and make it so hard for our selfs"
>> P.S.B. 1987
>>
>> Email: ja...@hj...
>> AIM: Marook=

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

[<ev...@ly...>]

And another thing. If this system should be integrated with XOOPS=20
(which I don't mean is the projects main goal), it should be written as=20=

a module that could be included with XOOPS.

On fredag, okt 4, 2002, at 13:38 Europe/Oslo, Marook Zuug Kenja wrote:

> So, we have a framework for displaying iCal files in a webbrowser.
> It's cool, and makes things a lot easier, makes co-workers access info=20=

> from everywhere.
>
> ...
> I know this is not a 1.0 thing, but we could start to work with his in=20=

> mind.
> I would love to give a hand...
>
>
> Marook Zuug Kenja
>
> [  MIB  ]
>
> 	Jakob Peterh=E4nsel
>
> "Tell me why, don't we try, not to break our hearts
>   and make it so hard for our selfs"
> P.S.B. 1987
>
> Email: ja...@hj...
> AIM: Marook=

Re: [PHPiCalendar-DEV] File or DB driven? Or both?

[<ev...@ly...>]

I also thought about extending the phpicalendar software to have many =20=

of these features, and your points are very good.
The drawback of the database method is that it would probably require =20=

someone with good cocoa skills to program either a plug-in for iCal
(the prefered way), og an application that publish the calendars for =20
you.

This system can go as big as it wants, and the problem is setting the =20=

requirements and the limits for it as well.
What functions should the system have? Should it be able to server =20
hundreds of users, from different companies/groups etc.
Or should each company/group have their own setup?

But it would for sure be ahead of others, and a major feature to =20
support editing/creating/deleting new events from the web.
If we want such a feature, then we would also have to make it =20
user-based for sure. I'm more into that db thing then, than making it =20=

all flat-file.

On fredag, okt 4, 2002, at 13:38 Europe/Oslo, Marook Zuug Kenja wrote:

> So, we have a framework for displaying iCal files in a webbrowser.
> It's cool, and makes things a lot easier, makes co-workers access info =
=20
> from everywhere.
>
> I would like to take this further. I would like to give options, and =20=

> most of all, I would like to make this work the other way round, =20
> managing the calendar via the browser, and subscribe to it (or parts =20=

> of if!) via app's like iCal.
>
> Aspects of the file method:
> - Easy publishing from app's like iCal.
> - No need to set up a Database
>
> Aspects of a database method:
> - Possibility to edit info from the web, without re-writing files.
> - Multiuser features
> - Integration with XOOPS (http://www.xoops.org)
> - Subscribe to parts of a calendar (could be done with files, but =20
> might be harder)
> - Might be able to support larger numbers of users/calendars.
>
>
> Would it be feasible to be able to create calendars via the web?
> Should it be done in a database?
>
> If we would like to make it user-based, I think we need to move the =20=

> data to a database, as the iCal file format does not support =20
> user-designation and/or restrictions.
> I see no problem in parsing an iCal file submitted via a Form upload, =20=

> and putting it in a MySQL db. Once there, it can be searched, shown, =20=

> and send via all forms of protocols. It would make it possible to =20
> subscribe to parts of the calendar, if needed.
>
> One usage for this could be, like this:
> You work in a department with shifting hours, and the manager makes =20=

> the work-shift-plan. You would like to subscribe to this calendar, but =
=20
> the one you sync to your Palm/iPod/phome, should only be the hours you =
=20
> work.
> - simple
> Subscribe to =20
> webcal://your.server.com/phpical/=20
> subscribe.php?ical=3Dworkshifts&subject=3DJoe Black
>
> Get the idea?
>
> I know this is not a 1.0 thing, but we could start to work with his in =
=20
> mind.
> I would love to give a hand...
>
>
> Marook Zuug Kenja
>
> [  MIB  ]
>
> 	Jakob Peterh=E4nsel
>
> "Tell me why, don't we try, not to break our hearts
>   and make it so hard for our selfs"
> P.S.B. 1987
>
> Email: ja...@hj...
> AIM: Marook=

[PHPiCalendar-DEV] File or DB driven? Or both?

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

So, we have a framework for displaying iCal files in a webbrowser.
It's cool, and makes things a lot easier, makes co-workers access info =20=

from everywhere.

I would like to take this further. I would like to give options, and =20
most of all, I would like to make this work the other way round, =20
managing the calendar via the browser, and subscribe to it (or parts of =20=

if!) via app's like iCal.

Aspects of the file method:
- Easy publishing from app's like iCal.
- No need to set up a Database

Aspects of a database method:
- Possibility to edit info from the web, without re-writing files.
- Multiuser features
- Integration with XOOPS (http://www.xoops.org)
- Subscribe to parts of a calendar (could be done with files, but might =20=

be harder)
- Might be able to support larger numbers of users/calendars.


Would it be feasible to be able to create calendars via the web?
Should it be done in a database?

If we would like to make it user-based, I think we need to move the =20
data to a database, as the iCal file format does not support =20
user-designation and/or restrictions.
I see no problem in parsing an iCal file submitted via a Form upload, =20=

and putting it in a MySQL db. Once there, it can be searched, shown, =20
and send via all forms of protocols. It would make it possible to =20
subscribe to parts of the calendar, if needed.

One usage for this could be, like this:
You work in a department with shifting hours, and the manager makes the =20=

work-shift-plan. You would like to subscribe to this calendar, but the =20=

one you sync to your Palm/iPod/phome, should only be the hours you work.
- simple
Subscribe to =20
webcal://your.server.com/phpical/=20
subscribe.php?ical=3Dworkshifts&subject=3DJoe Black

Get the idea?

I know this is not a 1.0 thing, but we could start to work with his in =20=

mind.
I would love to give a hand...


Marook Zuug Kenja

[  MIB  ]

	Jakob Peterh=E4nsel

"Tell me why, don't we try, not to break our hearts
   and make it so hard for our selfs"
P.S.B. 1987

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

Re: [PHPiCalendar-DEV] <no subject>

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

So did you get a chance to check out the CVS code and give it a once 
over? Its a pretty simple program that does a ton. Getting sessions up 
would help speed up the displaying of pages.

BTW, I grew up in MD / PA. Though I live in the SF Bay area now.


On Thursday, October 3, 2002, at 06:19 PM, Matt Jarjoura wrote:

> Sup everyone, just wanted to let you know I saw your ad for needing a
> sessions guru, and I here to assist. ;-)
>
> I'm a 21 year old Junior at University of Maryland, Baltimore County, 
> Comp
> Sci Major.  My side job is with an internet development company where I
> spend all weekend writing PHP code.
>
> Hmmm... Anything else?
>
> ==========================
>        Matt Jarjoura
> ==========================
> |  UMBC  | Phi-Delta 313 |
> ==========================
>
>
>
> -------------------------------------------------------
> 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] <no subject>

[Matt J. <mj...@um...>]

Sup everyone, just wanted to let you know I saw your ad for needing a
sessions guru, and I here to assist. ;-)

I'm a 21 year old Junior at University of Maryland, Baltimore County, Comp
Sci Major.  My side job is with an internet development company where I
spend all weekend writing PHP code.

Hmmm... Anything else?

==========================
       Matt Jarjoura
==========================
|  UMBC  | Phi-Delta 313 |
==========================

Re: [PHPiCalendar-DEV] interesting

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

On another note:

Re: [PHPiCalendar-DEV] interesting

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

Mike, where does your date_translation function get it's translations=20
from? If you check CVS, you can see in the date_functions.php file what=20=

I did with localizeDate(). If your solution is more generic and will=20
translate more, I would be happy to use it. However, I chose to go with=20=

what I was sure would work as we have it now. Plus, mine is flexible if=20=

needed. If yours covers all cases already, I would love to use it.

Yes, we got $week_start_day working entirely.

I am working on remote file viewing right now. This will have to be=20
made a configurable option as not everyone will want their web server=20
to display just any one's calendar.

-Jared

On Thursday, October 3, 2002, at 05:40  PM, Chad wrote:

> I think Jared wrote a date function last night and has it in CVS, we=20=

> decided to not go with setlocale since it is a submitted bug in=20
> Apple's Radar. Week date start should be working as well, even in=20
> month view. Having full language and theme support are the main=20
> features of the next rev so these are important. Check out CVS and=20
> check in your translations. :-)
>
> -C
>
> On Thursday, October 3, 2002, at 03:35  PM, Michel wrote:
>
>> Hi Chad,
>>
>> As I told you, retrieving distant calendars is not very difficult:=20
>> iWebCal is the proof. I can develop this for you. (see below my Sept=20=

>> 26 email)
>>
>> But this is not a priority. For the moment the language pref is an=20
>> issue. Just make a test yourself with your latest PHPiCalendar=20
>> release on a Mac OS X machine, you will see there is no setlocale()=20=

>> function working. The function I wrote date_translate() works on all=20=

>> systems: Linux where setlocale() works, as on Mac OS systems where=20
>> setlocale() does not work.
>>
>> // This function is to enable the date translation
>> // on Mac OS X when setlocale() doesn't work
>> //  because gettext is not installed by default
>>
>> function date_translate($format,$date=3D"") {
>> global $date_translate; if(!$date){$date=3Dtime();}
>> $date =3D strftime($format,$date);
>> foreach($date_translate as $k =3D> $v) {
>> $date =3D preg_replace("'".$k."'s",$v,$date);}
>> return $date; }
>>
>> Also the $week_start_day function does not work. Making this calendar=20=

>> unuseful in Europe. Do you want me to do it ? This is really an issue=20=

>> but very easy to correct.
>>
>> Best regards, Michael.
>> http://www.LaShampoo.com
>>
>>
>>
>>> From: Michel <mi...@la...>
>>> Date: Sept 26, 2002  20:50:33 Europe/Paris
>>> To: Chad <ch...@ch...>
>>> Object: R=E9p : Subscribe
>>>
>>>> Chad wrote :
>>>>
>>>>> in the list icals then you will have to check that you can read=20
>>>>> it, supress errors since people behind firewalls may have issues,=20=

>>>>> then list in the array for chosen calendars
>>>>
>>>> Since the calendars are available trough http:// that should work=20=

>>>> very well. On my website  (www.tetu.com) the list on the right is=20=

>>>> retrieved on every connection on a distant website with the=20
>>>> readfile() function. Very very easy.
>>>> # Retrieve the distant Calendar file...
>>>> $distant_cal =3D file("http://server/Calendar.ics");
>>>> # And check if the file is a good calendar file :
>>>> if($distant_cal[0] !=3D "BEGIN:VCALENDAR\n"){ BadCalendar(); }
>
>
>
> -------------------------------------------------------
> 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