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=