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=