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=