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=