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=