From kevin.olbrich at duke.edu Wed Feb 1 09:57:59 2006 From: kevin.olbrich at duke.edu (Kevin Olbrich) Date: Wed, 1 Feb 2006 09:57:59 -0500 Subject: [Rcalendar-devs] The difference between a todo item and an event Message-ID: <006901c6273f$e4e3b8f0$a2e31098@duhs.duke.edu> To summarize some musings I've had recently... Most PIM programs on the market today make a distinction between events and tasks. On the surface, this seems like a natural distinction. Events are things that happen at a particular time and tasks are things that need to be done. However, as I look at this, I can't help notice that tasks need to become events before they can be completed, and there is a lot of overlap in the required fields for these two data types. This suggests to me that these are really just variants of the same object. * Events are tasks scheduled for a specific time and duration * Tasks are unscheduled events We could generate an STI scheme to deal with this, but I would rather have one type of object that describes both events and tasks and just filter them as needed. Obviously rCalendar would need to be able to export the internal data structure to the iCal format, but the conversion to todo items vs. event items could be managed at export time. Incidentally, I also agree that engines appear to be the best choice for implementing this right now. _Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rcalendar-devs/attachments/20060201/1fcedcbe/attachment.htm From rgkaufman at gmail.com Wed Feb 1 15:21:32 2006 From: rgkaufman at gmail.com (Rob Kaufman) Date: Wed, 1 Feb 2006 12:21:32 -0800 Subject: [Rcalendar-devs] The difference between a todo item and an event In-Reply-To: <006901c6273f$e4e3b8f0$a2e31098@duhs.duke.edu> References: <006901c6273f$e4e3b8f0$a2e31098@duhs.duke.edu> Message-ID: <17112e2f0602011221q259e8017of3d9b6abd2040d6b@mail.gmail.com> Hi Kevin, I agree that Events and ToDos share a lot of fields / functionality, and I think they should inherit from a common parent, but they have some distinctions that many people utilize. First purely from the iCalendar view point ToDos and Events share all fields except: ToDo items * may be completed * have a name that equals "VTODO" * may have a percent complete * have a due field (which appears can be implied by dtstart+ duration). Events items * may have a time transparency * have a name that equals "VEVENT" * have a dtend (which can be implied by dtstart + duration) Conceptually an Event takes place in time and can not be completed before that time, where a ToDo takes place at any time and can (optionally) be done up to a due date. From a Ruby perspective its easiest to use the superb inheritance model to handle these distinctions. From a database efficiency point of view, I'm not sure how much is gained / lost from joining the two types in one table. Also worth thinking about, keeping them separate lets you have different category setups for Events than ToDos. I did some work a while back optimising the various fields in the iCalendar spec for implementation in Ruby (for a project that was then scrapped). I'm sure I have a set of UML (ish) diagrams one showing the unoptimised iCalendar and vCard fields and one dividing things up for use as parent/child classes and modules so that everything stays DRY. I'll dig them up and post them somewhere online if your interested. Just Some Thoughts, Rob Kaufman On 2/1/06, Kevin Olbrich wrote: > > To summarize some musings I've had recently... > > Most PIM programs on the market today make a distinction between events and > tasks. On the surface, this seems like a natural distinction. Events are > things that happen at a particular time and tasks are things that need to be > done. > > However, as I look at this, I can't help notice that tasks need to become > events before they can be completed, and there is a lot of overlap in the > required fields for these two data types. This suggests to me that these > are really just variants of the same object. > > * Events are tasks scheduled for a specific time and duration > * Tasks are unscheduled events > > We could generate an STI scheme to deal with this, but I would rather have > one type of object that describes both events and tasks and just filter them > as needed. > > Obviously rCalendar would need to be able to export the internal data > structure to the iCal format, but the conversion to todo items vs. event > items could be managed at export time. > > Incidentally, I also agree that engines appear to be the best choice for > implementing this right now. > > _Kevin > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > From dandrew.thompson at gmail.com Wed Feb 1 15:32:17 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Wed, 1 Feb 2006 12:32:17 -0800 Subject: [Rcalendar-devs] The difference between a todo item and an event In-Reply-To: <17112e2f0602011221q259e8017of3d9b6abd2040d6b@mail.gmail.com> References: <006901c6273f$e4e3b8f0$a2e31098@duhs.duke.edu> <17112e2f0602011221q259e8017of3d9b6abd2040d6b@mail.gmail.com> Message-ID: <7b297ea20602011232y2fdb5f39jdda6595642f13d48@mail.gmail.com> Rob, I would enjoy looking over what diagrams you do have and I'm sure that others would appreciate learning from your work. Could you post them on the wiki? Or feel free to send them to my personal email ( dandrew.thompson at gmail.com) and I can post them. Here's the wiki https://opensvn.csie.org/traccgi/rcalendar/trac.cgi/wiki Dave On 2/1/06, Rob Kaufman wrote: > > Hi Kevin, > I agree that Events and ToDos share a lot of fields / functionality, > and I think they should inherit from a common parent, but they have > some distinctions that many people utilize. > > First purely from the iCalendar view point ToDos and Events share all > fields except: > ToDo items > * may be completed > * have a name that equals "VTODO" > * may have a percent complete > * have a due field (which appears can be implied by dtstart+ > duration). > Events items > * may have a time transparency > * have a name that equals "VEVENT" > * have a dtend (which can be implied by dtstart + duration) > > Conceptually an Event takes place in time and can not be completed > before that time, where a ToDo takes place at any time and can > (optionally) be done up to a due date. From a Ruby perspective its > easiest to use the superb inheritance model to handle these > distinctions. From a database efficiency point of view, I'm not sure > how much is gained / lost from joining the two types in one table. > > Also worth thinking about, keeping them separate lets you have > different category setups for Events than ToDos. > > I did some work a while back optimising the various fields in the > iCalendar spec for implementation in Ruby (for a project that was then > scrapped). I'm sure I have a set of UML (ish) diagrams one showing > the unoptimised iCalendar and vCard fields and one dividing things up > for use as parent/child classes and modules so that everything stays > DRY. I'll dig them up and post them somewhere online if your > interested. > > Just Some Thoughts, > Rob Kaufman > On 2/1/06, Kevin Olbrich wrote: > > > > To summarize some musings I've had recently... > > > > Most PIM programs on the market today make a distinction between events > and > > tasks. On the surface, this seems like a natural distinction. Events > are > > things that happen at a particular time and tasks are things that need > to be > > done. > > > > However, as I look at this, I can't help notice that tasks need to > become > > events before they can be completed, and there is a lot of overlap in > the > > required fields for these two data types. This suggests to me that > these > > are really just variants of the same object. > > > > * Events are tasks scheduled for a specific time and duration > > * Tasks are unscheduled events > > > > We could generate an STI scheme to deal with this, but I would rather > have > > one type of object that describes both events and tasks and just filter > them > > as needed. > > > > Obviously rCalendar would need to be able to export the internal data > > structure to the iCal format, but the conversion to todo items vs. event > > items could be managed at export time. > > > > Incidentally, I also agree that engines appear to be the best choice for > > implementing this right now. > > > > _Kevin > > _______________________________________________ > > Rcalendar-devs mailing list > > Rcalendar-devs at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > > > > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -- ~~~~~~~~~~~~~~~~~~~ David Andrew Thompson http://dathompson.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rcalendar-devs/attachments/20060201/96de2294/attachment.htm From dandrew.thompson at gmail.com Sun Feb 5 17:49:30 2006 From: dandrew.thompson at gmail.com (David Andrew Thompson) Date: Sun, 5 Feb 2006 14:49:30 -0800 Subject: [Rcalendar-devs] New ical UML's and resources on Wiki Message-ID: <7b297ea20602051449o26b3215cn2a04dcc85e4bdf74@mail.gmail.com> Please take a look at our new posted resources for the ical standard, as well as some UML's on the trac wiki. https://opensvn.csie.org/traccgi/rcalendar/trac.cgi/wiki/IcalendarReferences Also, a big thank you to Rob Kaufman for posting this information and his hard work on diagramming a great ical spread. Dave -- ~~~~~~~~~~~~~~~~~~~ David Andrew Thompson http://dathompson.blogspot.com ---------- Forwarded message ---------- From: Rob Kaufman Date: Feb 5, 2006 11:29 AM Subject: Re: [Rcalendar-devs] The difference between a todo item and an event To: D'Andrew Dave Thompson Hi Dave, I've posted to a new page (https://opensvn.csie.org/traccgi/rcalendar/trac.cgi/wiki/IcalendarReferences) and added some links I've found useful. I can't seem to find a copy of the UML diagram before I pulled all the components apart, but the basic picture is the same anyhow. Let me know if some other format would be better. Rob From greg.freemyer at gmail.com Thu Feb 23 20:40:57 2006 From: greg.freemyer at gmail.com (Greg Freemyer) Date: Thu, 23 Feb 2006 20:40:57 -0500 Subject: [Rcalendar-devs] Date picker Message-ID: <87f94c370602231740v24a0f89am2e9beeb0e4666158@mail.gmail.com> I've been using the date picker engine recently in a project of mine. Seems to work pretty well. I assume a date picker will be needed at some point in the rcalandar project so the date_engine might be a good choice when the project gets to that point. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century From rgkaufman at gmail.com Tue Feb 28 11:02:13 2006 From: rgkaufman at gmail.com (Rob Kaufman) Date: Tue, 28 Feb 2006 08:02:13 -0800 Subject: [Rcalendar-devs] Datastore formats Message-ID: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> Hi All, I've been thinking about data stores lately and was wondering what peoples thoughts are. Right now I see two basic options: Database and .ics files. The database option seems pretty obvious since we're talking about rails, its merits are speed and keeping everything in one place, but the file option seems to have some allure. By keeping calendars as files a user could potential store those files on a WebDAV enabled directory. This would give (basic) calendar sharing right out the gate without extra work for us. How sever are the downsides to this? Is there more to sharing iCalendars through WebDAV that I'm missing? Thanks For Your Thoughts, Rob Kaufman From rrthompson at gmail.com Tue Feb 28 11:39:41 2006 From: rrthompson at gmail.com (Ryan Thompson) Date: Tue, 28 Feb 2006 08:39:41 -0800 Subject: [Rcalendar-devs] Datastore formats In-Reply-To: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> Message-ID: phpiCalendar did it like that. The calendar file is a subversion uri e.g. https://localhost/svn/UserName.ics Subversion auto-increments the current revision for any changes and the calendar app automatically reflects any outside changes made to https://localhost/svn/UserName.ics Multiple tier setups might work better like this as the files can be on a shared svn repository instead of a local file on one server that would have to be replicated to the other front-end machines. Ryan Thompson On 2/28/06, Rob Kaufman wrote: > > Hi All, > I've been thinking about data stores lately and was wondering what > peoples thoughts are. Right now I see two basic options: Database and > .ics files. The database option seems pretty obvious since we're > talking about rails, its merits are speed and keeping everything in > one place, but the file option seems to have some allure. By keeping > calendars as files a user could potential store those files on a > WebDAV enabled directory. This would give (basic) calendar sharing > right out the gate without extra work for us. How sever are the > downsides to this? Is there more to sharing iCalendars through WebDAV > that I'm missing? > > Thanks For Your Thoughts, > Rob Kaufman > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -- Ryan Thompson ryan at rrt.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rcalendar-devs/attachments/20060228/c0eb47d1/attachment.htm From pzingg at kentfieldschools.org Tue Feb 28 12:48:16 2006 From: pzingg at kentfieldschools.org (Peter Zingg) Date: Tue, 28 Feb 2006 09:48:16 -0800 Subject: [Rcalendar-devs] Datastore formats In-Reply-To: References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> Message-ID: <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> The SchoolTool system (which is built on top of Zope) intercepts a WebDAV PUT of an .ics file, parses it and loads the events into a database. When given a request to subscribe to the iCal file, it builds one on the fly out of the database. Last time I looked phpiCalendar waits until someone tries to view the calendar, then checks to see if the ics file has a newer timestamp than the cache, and parses the ics into its database. Subscribers get a copy of the file (no dynamic rebuilding of the ics necessary). I was looking at Kerio mail server; they appear to determine the proper storage based on the username and password, not by a file- system path the way SchooTool and phpiCalendar do. --Peter Zingg On Feb 28, 2006, at 8:39 AM, Ryan Thompson wrote: > phpiCalendar did it like that. The calendar file is a subversion > uri e.g. https://localhost/svn/UserName.ics > > Subversion auto-increments the current revision for any changes and > the calendar app automatically reflects any outside changes made to > https://localhost/svn/UserName.ics > > Multiple tier setups might work better like this as the files can > be on a shared svn repository instead of a local file on one server > that would have to be replicated to the other front-end machines. > > Ryan Thompson > > On 2/28/06, Rob Kaufman wrote: Hi All, > I've been thinking about data stores lately and was wondering what > peoples thoughts are. Right now I see two basic options: Database and > .ics files. The database option seems pretty obvious since we're > talking about rails, its merits are speed and keeping everything in > one place, but the file option seems to have some allure. By keeping > calendars as files a user could potential store those files on a > WebDAV enabled directory. This would give (basic) calendar sharing > right out the gate without extra work for us. How sever are the > downsides to this? Is there more to sharing iCalendars through WebDAV > that I'm missing? > > Thanks For Your Thoughts, > Rob Kaufman > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > > > -- > Ryan Thompson > ryan at rrt.ca > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs From gsslist+rcal at anthropohedron.net Tue Feb 28 13:37:35 2006 From: gsslist+rcal at anthropohedron.net (Gregory Seidman) Date: Tue, 28 Feb 2006 13:37:35 -0500 Subject: [Rcalendar-devs] Datastore formats In-Reply-To: <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> Message-ID: <20060228183735.GA28560@anthropohedron.net> On Tue, Feb 28, 2006 at 09:48:16AM -0800, Peter Zingg wrote: } The SchoolTool system (which is built on top of Zope) intercepts a } WebDAV PUT of an .ics file, parses it and loads the events into a } database. When given a request to subscribe to the iCal file, it } builds one on the fly out of the database. } } Last time I looked phpiCalendar waits until someone tries to view the } calendar, then checks to see if the ics file has a newer timestamp } than the cache, and parses the ics into its database. Subscribers } get a copy of the file (no dynamic rebuilding of the ics necessary). [...] Neither of these are ideal. It makes sense to have a static ical file for reading (since we can expect a lot more reading than writing). I suggest the following: When a changed ical file comes through WebDAV (PUT) it needs to be parsed into the database, but the received file itself can be stored as that static file. If it's stored under public in the right place then as long as it exists it will get served statically by Rails. When a database change occurs that would invalidate it, we delete the ical file so that on the next request for the file our controller gets called and we regenerate it. The hard part is dealing with LOCK (and UNLOCK) requests on the file. Correct behavior of a calendar WebDAV client making a change is to: 1) HTTP LOCK 2) HTTP GET 3) merge changes 4) HTTP PUT 5) HTTP UNLOCK I'm not even sure if Rails understands LOCK and UNLOCK methods. (The Agile book does not mention them as possible values for the request.method.) One way or another, though, we need to support locking of not just the file, but of the data. Changes should not be allowed in the database while the file is locked by WebDAV. } --Peter Zingg --Greg From rrthompson at gmail.com Tue Feb 28 15:46:39 2006 From: rrthompson at gmail.com (Ryan Thompson) Date: Tue, 28 Feb 2006 12:46:39 -0800 Subject: [Rcalendar-devs] Datastore formats In-Reply-To: <20060228183735.GA28560@anthropohedron.net> References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> <20060228183735.GA28560@anthropohedron.net> Message-ID: That all seems like a lot of unecessary work. If the app simply understands WebDAV, it can access a svn repo containing the ics files, as can any other client. is there a major benefit i am missing here? Ryan On 2/28/06, Gregory Seidman wrote: > > On Tue, Feb 28, 2006 at 09:48:16AM -0800, Peter Zingg wrote: > } The SchoolTool system (which is built on top of Zope) intercepts a > } WebDAV PUT of an .ics file, parses it and loads the events into a > } database. When given a request to subscribe to the iCal file, it > } builds one on the fly out of the database. > } > } Last time I looked phpiCalendar waits until someone tries to view the > } calendar, then checks to see if the ics file has a newer timestamp > } than the cache, and parses the ics into its database. Subscribers > } get a copy of the file (no dynamic rebuilding of the ics necessary). > [...] > > Neither of these are ideal. It makes sense to have a static ical file for > reading (since we can expect a lot more reading than writing). I suggest > the following: > > When a changed ical file comes through WebDAV (PUT) it needs to be parsed > into the database, but the received file itself can be stored as that > static file. If it's stored under public in the right place then as long > as > it exists it will get served statically by Rails. When a database change > occurs that would invalidate it, we delete the ical file so that on the > next request for the file our controller gets called and we regenerate it. > > The hard part is dealing with LOCK (and UNLOCK) requests on the file. > Correct behavior of a calendar WebDAV client making a change is to: > > 1) HTTP LOCK > 2) HTTP GET > 3) merge changes > 4) HTTP PUT > 5) HTTP UNLOCK > > I'm not even sure if Rails understands LOCK and UNLOCK methods. (The Agile > book does not mention them as possible values for the request.method.) One > way or another, though, we need to support locking of not just the file, > but of the data. Changes should not be allowed in the database while the > file is locked by WebDAV. > > } --Peter Zingg > --Greg > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -- Ryan Thompson ryan at rrt.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rcalendar-devs/attachments/20060228/82d9ca78/attachment.htm From dandrew.thompson at gmail.com Tue Feb 28 15:57:36 2006 From: dandrew.thompson at gmail.com (David Andrew Thompson) Date: Tue, 28 Feb 2006 12:57:36 -0800 Subject: [Rcalendar-devs] Datastore formats In-Reply-To: <20060228183735.GA28560@anthropohedron.net> References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> <20060228183735.GA28560@anthropohedron.net> Message-ID: <7b297ea20602281257v4dfff643x333b894bb9ad01d1@mail.gmail.com> Regarding data storage: I agree that having static .ics files is a positive redundancy and will substantially reduce overhead since there will be far more read-only hits than updates. However, I also feel that it would be in the best interest of the Rails convention to keep the primary data stored in a DB. This will allow for easier manipulation within other engine componentry. So, it appears that we need both the DB and the static .ics files. It is also apparent that we need some WebDAV functionality. After all, an iCal implementation does presume the usage of an iCal compliant client. This would seem to necessitate engine componentry to handle requests from these clients on WebDAV protocol. Consequently, I've laid out a couple of flowcharts showing one possible solution for combining a WebDAV controller (to handle the WebDAV requests/processing) and an iCal controller (to handle the DB processing and static .ics manipulation). The iCal Controller really could be broken into two controllers (one to parse .ics and integrate with the DB, and one to manipulate the .ics files), but I chose to collapse the functionality into one controller for now. I can't seem to upload any files to the Trac site at the moment, so I put them on my company site temporarily. There is a pdf and the master copy in OpenOffice Draw. http://www.policorp.com/files/rcal/rCal_Flow.pdf http://www.policorp.com/files/rcal/rCal_Flow.odg I will post them to the Trac site as soon as I am able. Great discussion! Dave On 2/28/06, Gregory Seidman wrote: > On Tue, Feb 28, 2006 at 09:48:16AM -0800, Peter Zingg wrote: > } The SchoolTool system (which is built on top of Zope) intercepts a > } WebDAV PUT of an .ics file, parses it and loads the events into a > } database. When given a request to subscribe to the iCal file, it > } builds one on the fly out of the database. > } > } Last time I looked phpiCalendar waits until someone tries to view the > } calendar, then checks to see if the ics file has a newer timestamp > } than the cache, and parses the ics into its database. Subscribers > } get a copy of the file (no dynamic rebuilding of the ics necessary). > [...] > > Neither of these are ideal. It makes sense to have a static ical file for > reading (since we can expect a lot more reading than writing). I suggest > the following: > > When a changed ical file comes through WebDAV (PUT) it needs to be parsed > into the database, but the received file itself can be stored as that > static file. If it's stored under public in the right place then as long as > it exists it will get served statically by Rails. When a database change > occurs that would invalidate it, we delete the ical file so that on the > next request for the file our controller gets called and we regenerate it. > > The hard part is dealing with LOCK (and UNLOCK) requests on the file. > Correct behavior of a calendar WebDAV client making a change is to: > > 1) HTTP LOCK > 2) HTTP GET > 3) merge changes > 4) HTTP PUT > 5) HTTP UNLOCK > > I'm not even sure if Rails understands LOCK and UNLOCK methods. (The Agile > book does not mention them as possible values for the request.method.) One > way or another, though, we need to support locking of not just the file, > but of the data. Changes should not be allowed in the database while the > file is locked by WebDAV. > > } --Peter Zingg > --Greg > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -- ~~~~~~~~~~~~~~~~~~~ David Andrew Thompson http://dathompson.blogspot.com From dandrew.thompson at gmail.com Tue Feb 28 16:08:19 2006 From: dandrew.thompson at gmail.com (David Andrew Thompson) Date: Tue, 28 Feb 2006 13:08:19 -0800 Subject: [Rcalendar-devs] Datastore formats In-Reply-To: <7b297ea20602281257v4dfff643x333b894bb9ad01d1@mail.gmail.com> References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> <20060228183735.GA28560@anthropohedron.net> <7b297ea20602281257v4dfff643x333b894bb9ad01d1@mail.gmail.com> Message-ID: <7b297ea20602281308n41cadc1an7d1ad1ce5613a48f@mail.gmail.com> Regarding SVN: I am a little nervous about the idea of relying upon supplemental servers/functionality, for a couple of reasons: 1. Simplicity is always the best recipe for providing a useful tool. If you can't simply plug-and-play, it just won't be used. 2. Not everyone is going to have access to, or know how to implement an SVN server (remember that user-reach means that most people will be using this engine with apps that they are hosting with typical ISP's, who don't normally provide SVN) 3. Requiring SVN would mean a tremendous amount of set-up work for individuals who want to use WebDAV but do not want to host their .ics files with third party SVN providers (either for security reasons, or a number of other reasons). Keeping the WebDAV controller separate from the iCal controller might allow others to implement an SVN plugin to our engine should they desire. Dave On 2/28/06, David Andrew Thompson wrote: > Regarding data storage: > > I agree that having static .ics files is a positive redundancy and > will substantially reduce overhead since there will be far more > read-only hits than updates. > > However, I also feel that it would be in the best interest of the > Rails convention to keep the primary data stored in a DB. This will > allow for easier manipulation within other engine componentry. > > So, it appears that we need both the DB and the static .ics files. > > It is also apparent that we need some WebDAV functionality. After all, > an iCal implementation does presume the usage of an iCal compliant > client. This would seem to necessitate engine componentry to handle > requests from these clients on WebDAV protocol. > > Consequently, I've laid out a couple of flowcharts showing one > possible solution for combining a WebDAV controller (to handle the > WebDAV requests/processing) and an iCal controller (to handle the DB > processing and static .ics manipulation). The iCal Controller really > could be broken into two controllers (one to parse .ics and integrate > with the DB, and one to manipulate the .ics files), but I chose to > collapse the functionality into one controller for now. > > I can't seem to upload any files to the Trac site at the moment, so I > put them on my company site temporarily. There is a pdf and the master > copy in OpenOffice Draw. > > http://www.policorp.com/files/rcal/rCal_Flow.pdf > http://www.policorp.com/files/rcal/rCal_Flow.odg > > I will post them to the Trac site as soon as I am able. > > Great discussion! > > Dave > > On 2/28/06, Gregory Seidman wrote: > > On Tue, Feb 28, 2006 at 09:48:16AM -0800, Peter Zingg wrote: > > } The SchoolTool system (which is built on top of Zope) intercepts a > > } WebDAV PUT of an .ics file, parses it and loads the events into a > > } database. When given a request to subscribe to the iCal file, it > > } builds one on the fly out of the database. > > } > > } Last time I looked phpiCalendar waits until someone tries to view the > > } calendar, then checks to see if the ics file has a newer timestamp > > } than the cache, and parses the ics into its database. Subscribers > > } get a copy of the file (no dynamic rebuilding of the ics necessary). > > [...] > > > > Neither of these are ideal. It makes sense to have a static ical file for > > reading (since we can expect a lot more reading than writing). I suggest > > the following: > > > > When a changed ical file comes through WebDAV (PUT) it needs to be parsed > > into the database, but the received file itself can be stored as that > > static file. If it's stored under public in the right place then as long as > > it exists it will get served statically by Rails. When a database change > > occurs that would invalidate it, we delete the ical file so that on the > > next request for the file our controller gets called and we regenerate it. > > > > The hard part is dealing with LOCK (and UNLOCK) requests on the file. > > Correct behavior of a calendar WebDAV client making a change is to: > > > > 1) HTTP LOCK > > 2) HTTP GET > > 3) merge changes > > 4) HTTP PUT > > 5) HTTP UNLOCK > > > > I'm not even sure if Rails understands LOCK and UNLOCK methods. (The Agile > > book does not mention them as possible values for the request.method.) One > > way or another, though, we need to support locking of not just the file, > > but of the data. Changes should not be allowed in the database while the > > file is locked by WebDAV. > > > > } --Peter Zingg > > --Greg > > > > _______________________________________________ > > Rcalendar-devs mailing list > > Rcalendar-devs at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > > > > -- > ~~~~~~~~~~~~~~~~~~~ > David Andrew Thompson > http://dathompson.blogspot.com > -- ~~~~~~~~~~~~~~~~~~~ David Andrew Thompson http://dathompson.blogspot.com From rrthompson at gmail.com Tue Feb 28 16:38:43 2006 From: rrthompson at gmail.com (Ryan Thompson) Date: Tue, 28 Feb 2006 13:38:43 -0800 Subject: [Rcalendar-devs] Fwd: Datastore formats In-Reply-To: References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> <20060228183735.GA28560@anthropohedron.net> <7b297ea20602281257v4dfff643x333b894bb9ad01d1@mail.gmail.com> <7b297ea20602281308n41cadc1an7d1ad1ce5613a48f@mail.gmail.com> Message-ID: ---------- Forwarded message ---------- From: Ryan Thompson Date: Feb 28, 2006 1:38 PM Subject: Re: [Rcalendar-devs] Datastore formats To: David Andrew Thompson Requiring SVN isn't quite what I meant as SVN really only comes into play where concurrency and larger environments are concerned. I think it makes total sense that someone can write a "SVN URI handler for filename" plugin for use in such deployments. The issue I'm wondering about is working seamlessly with 3rd party iCal clients, which a lot of users will probably want to do. They want to make a change once so that mean read + write from clients. Doesn't that implie that rCalendar has to handle WebDAV _or_ the physical ICS file must be made available on the network somehow (apache dav + local file access?). If we ignore the WebDAV handling requirement up front, then we/someone have to provide it on the back-end via something like the afformentioned plugin. This is all off the top of my head so if i'm way off... Thanks, Ryan On 2/28/06, David Andrew Thompson wrote: > > Regarding SVN: > > I am a little nervous about the idea of relying upon supplemental > servers/functionality, for a couple of reasons: > > 1. Simplicity is always the best recipe for providing a useful tool. > If you can't simply plug-and-play, it just won't be used. > 2. Not everyone is going to have access to, or know how to implement > an SVN server (remember that user-reach means that most people will be > using this engine with apps that they are hosting with typical ISP's, > who don't normally provide SVN) > 3. Requiring SVN would mean a tremendous amount of set-up work for > individuals who want to use WebDAV but do not want to host their .ics > files with third party SVN providers (either for security reasons, or > a number of other reasons). > > Keeping the WebDAV controller separate from the iCal controller might > allow others to implement an SVN plugin to our engine should they > desire. > > Dave > > On 2/28/06, David Andrew Thompson wrote: > > Regarding data storage: > > > > I agree that having static .ics files is a positive redundancy and > > will substantially reduce overhead since there will be far more > > read-only hits than updates. > > > > However, I also feel that it would be in the best interest of the > > Rails convention to keep the primary data stored in a DB. This will > > allow for easier manipulation within other engine componentry. > > > > So, it appears that we need both the DB and the static .ics files. > > > > It is also apparent that we need some WebDAV functionality. After all, > > an iCal implementation does presume the usage of an iCal compliant > > client. This would seem to necessitate engine componentry to handle > > requests from these clients on WebDAV protocol. > > > > Consequently, I've laid out a couple of flowcharts showing one > > possible solution for combining a WebDAV controller (to handle the > > WebDAV requests/processing) and an iCal controller (to handle the DB > > processing and static .ics manipulation). The iCal Controller really > > could be broken into two controllers (one to parse .ics and integrate > > with the DB, and one to manipulate the .ics files), but I chose to > > collapse the functionality into one controller for now. > > > > I can't seem to upload any files to the Trac site at the moment, so I > > put them on my company site temporarily. There is a pdf and the master > > copy in OpenOffice Draw. > > > > http://www.policorp.com/files/rcal/rCal_Flow.pdf > > http://www.policorp.com/files/rcal/rCal_Flow.odg > > > > I will post them to the Trac site as soon as I am able. > > > > Great discussion! > > > > Dave > > > > On 2/28/06, Gregory Seidman wrote: > > > On Tue, Feb 28, 2006 at 09:48:16AM -0800, Peter Zingg wrote: > > > } The SchoolTool system (which is built on top of Zope) intercepts a > > > } WebDAV PUT of an .ics file, parses it and loads the events into a > > > } database. When given a request to subscribe to the iCal file, it > > > } builds one on the fly out of the database. > > > } > > > } Last time I looked phpiCalendar waits until someone tries to view > the > > > } calendar, then checks to see if the ics file has a newer timestamp > > > } than the cache, and parses the ics into its database. Subscribers > > > } get a copy of the file (no dynamic rebuilding of the ics necessary). > > > [...] > > > > > > Neither of these are ideal. It makes sense to have a static ical file > for > > > reading (since we can expect a lot more reading than writing). I > suggest > > > the following: > > > > > > When a changed ical file comes through WebDAV (PUT) it needs to be > parsed > > > into the database, but the received file itself can be stored as that > > > static file. If it's stored under public in the right place then as > long as > > > it exists it will get served statically by Rails. When a database > change > > > occurs that would invalidate it, we delete the ical file so that on > the > > > next request for the file our controller gets called and we regenerate > it. > > > > > > The hard part is dealing with LOCK (and UNLOCK) requests on the file. > > > Correct behavior of a calendar WebDAV client making a change is to: > > > > > > 1) HTTP LOCK > > > 2) HTTP GET > > > 3) merge changes > > > 4) HTTP PUT > > > 5) HTTP UNLOCK > > > > > > I'm not even sure if Rails understands LOCK and UNLOCK methods. (The > Agile > > > book does not mention them as possible values for the request.method.) > One > > > way or another, though, we need to support locking of not just the > file, > > > but of the data. Changes should not be allowed in the database while > the > > > file is locked by WebDAV. > > > > > > } --Peter Zingg > > > --Greg > > > > > > _______________________________________________ > > > Rcalendar-devs mailing list > > > Rcalendar-devs at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > > > > > > > > -- > > ~~~~~~~~~~~~~~~~~~~ > > David Andrew Thompson > > http://dathompson.blogspot.com > > > > > -- > ~~~~~~~~~~~~~~~~~~~ > David Andrew Thompson > http://dathompson.blogspot.com > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -- Ryan Thompson ryan at rrt.ca -- Ryan Thompson ryan at rrt.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rcalendar-devs/attachments/20060228/c52f60cd/attachment.htm From pzingg at kentfieldschools.org Tue Feb 28 16:51:21 2006 From: pzingg at kentfieldschools.org (Peter Zingg) Date: Tue, 28 Feb 2006 13:51:21 -0800 Subject: [Rcalendar-devs] Related to shared calendar datastore/WebDAV Message-ID: <604F245C-37BE-4254-89F7-F7A44806F76C@kentfieldschools.org> Does anyone know if Apple's iCal (or other more group-oriented clients, such as Outlook/Entourage, Mozilla or Evolution) have a concept of a published calendar with multiple writers? This is what my organization (a school district) is looking for. The typical use case is an executive (our principal or superintendent) and an appointment secretary. It would be great if both the exec and the secretary could use a rich client like those mentioned above and *publish changes to the same WebDAV ics file*. This is what Apple is *not* doing with their "i" apps. It's publish *or* subscribe, not both. Guess that why it's not called weCal. I assume there is enough meta-info in an ics file to determine how to deal with conflicts, and WebDAV locks would help to keep things in sync. Just something else for the wish list. Peter Zingg Technology Coordinator Kentfield School District Kentfield, CA From dandrew.thompson at gmail.com Tue Feb 28 16:51:45 2006 From: dandrew.thompson at gmail.com (David Andrew Thompson) Date: Tue, 28 Feb 2006 13:51:45 -0800 Subject: [Rcalendar-devs] Fwd: Datastore formats In-Reply-To: References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> <20060228183735.GA28560@anthropohedron.net> <7b297ea20602281257v4dfff643x333b894bb9ad01d1@mail.gmail.com> <7b297ea20602281308n41cadc1an7d1ad1ce5613a48f@mail.gmail.com> Message-ID: <7b297ea20602281351i35ceee0cm4a1762d081291c1c@mail.gmail.com> I completely agree...WebDAV functionality is a must. The main concern, in my mind, comes down to the ability to create a WebDAV Controller to mitigate the protocol. If this is possible, we can do whatever we want with the iCal Controller (even allowing for an SVN alternative setting). It sounds as if Gregory might have a good understanding of the protocol....How about it, Gregory....feel like writing the WebDAV Controller? ;) In the flowcharts (see previous email) I attempted to separate the layers of concern (WebDAV/iCAL). I don't know if this is the best solution, but it is a start. Dave On 2/28/06, Ryan Thompson wrote: > > > ---------- Forwarded message ---------- > From: Ryan Thompson > Date: Feb 28, 2006 1:38 PM > Subject: Re: [Rcalendar-devs] Datastore formats > To: David Andrew Thompson > > > Requiring SVN isn't quite what I meant as SVN really only comes into play > where concurrency and larger environments are concerned. I think it makes > total sense that someone can write a "SVN URI handler for filename" plugin > for use in such deployments. > > The issue I'm wondering about is working seamlessly with 3rd party iCal > clients, which a lot of users will probably want to do. They want to make a > change once so that mean read + write from clients. > > Doesn't that implie that rCalendar has to handle WebDAV _or_ the physical > ICS file must be made available on the network somehow (apache dav + local > file access?). > > If we ignore the WebDAV handling requirement up front, then we/someone have > to provide it on the back-end via something like the afformentioned plugin. > > This is all off the top of my head so if i'm way off... > > Thanks, > Ryan > > > On 2/28/06, David Andrew Thompson < dandrew.thompson at gmail.com> wrote: > > Regarding SVN: > > > > I am a little nervous about the idea of relying upon supplemental > > servers/functionality, for a couple of reasons: > > > > 1. Simplicity is always the best recipe for providing a useful tool. > > If you can't simply plug-and-play, it just won't be used. > > 2. Not everyone is going to have access to, or know how to implement > > an SVN server (remember that user-reach means that most people will be > > using this engine with apps that they are hosting with typical ISP's, > > who don't normally provide SVN) > > 3. Requiring SVN would mean a tremendous amount of set-up work for > > individuals who want to use WebDAV but do not want to host their .ics > > files with third party SVN providers (either for security reasons, or > > a number of other reasons). > > > > Keeping the WebDAV controller separate from the iCal controller might > > allow others to implement an SVN plugin to our engine should they > > desire. > > > > Dave > > > > On 2/28/06, David Andrew Thompson wrote: > > > Regarding data storage: > > > > > > I agree that having static .ics files is a positive redundancy and > > > will substantially reduce overhead since there will be far more > > > read-only hits than updates. > > > > > > However, I also feel that it would be in the best interest of the > > > Rails convention to keep the primary data stored in a DB. This will > > > allow for easier manipulation within other engine componentry. > > > > > > So, it appears that we need both the DB and the static .ics files. > > > > > > It is also apparent that we need some WebDAV functionality. After all, > > > an iCal implementation does presume the usage of an iCal compliant > > > client. This would seem to necessitate engine componentry to handle > > > requests from these clients on WebDAV protocol. > > > > > > Consequently, I've laid out a couple of flowcharts showing one > > > possible solution for combining a WebDAV controller (to handle the > > > WebDAV requests/processing) and an iCal controller (to handle the DB > > > processing and static .ics manipulation). The iCal Controller really > > > could be broken into two controllers (one to parse .ics and integrate > > > with the DB, and one to manipulate the .ics files), but I chose to > > > collapse the functionality into one controller for now. > > > > > > I can't seem to upload any files to the Trac site at the moment, so I > > > put them on my company site temporarily. There is a pdf and the master > > > copy in OpenOffice Draw. > > > > > > http://www.policorp.com/files/rcal/rCal_Flow.pdf > > > http://www.policorp.com/files/rcal/rCal_Flow.odg > > > > > > I will post them to the Trac site as soon as I am able. > > > > > > Great discussion! > > > > > > Dave > > > > > > On 2/28/06, Gregory Seidman < gsslist+rcal at anthropohedron.net> wrote: > > > > On Tue, Feb 28, 2006 at 09:48:16AM -0800, Peter Zingg wrote: > > > > } The SchoolTool system (which is built on top of Zope) intercepts a > > > > } WebDAV PUT of an .ics file, parses it and loads the events into a > > > > } database. When given a request to subscribe to the iCal file, it > > > > } builds one on the fly out of the database. > > > > } > > > > } Last time I looked phpiCalendar waits until someone tries to view > the > > > > } calendar, then checks to see if the ics file has a newer timestamp > > > > } than the cache, and parses the ics into its database. Subscribers > > > > } get a copy of the file (no dynamic rebuilding of the ics necessary). > > > > [...] > > > > > > > > Neither of these are ideal. It makes sense to have a static ical file > for > > > > reading (since we can expect a lot more reading than writing). I > suggest > > > > the following: > > > > > > > > When a changed ical file comes through WebDAV (PUT) it needs to be > parsed > > > > into the database, but the received file itself can be stored as that > > > > static file. If it's stored under public in the right place then as > long as > > > > it exists it will get served statically by Rails. When a database > change > > > > occurs that would invalidate it, we delete the ical file so that on > the > > > > next request for the file our controller gets called and we regenerate > it. > > > > > > > > The hard part is dealing with LOCK (and UNLOCK) requests on the file. > > > > Correct behavior of a calendar WebDAV client making a change is to: > > > > > > > > 1) HTTP LOCK > > > > 2) HTTP GET > > > > 3) merge changes > > > > 4) HTTP PUT > > > > 5) HTTP UNLOCK > > > > > > > > I'm not even sure if Rails understands LOCK and UNLOCK methods. (The > Agile > > > > book does not mention them as possible values for the request.method.) > One > > > > way or another, though, we need to support locking of not just the > file, > > > > but of the data. Changes should not be allowed in the database while > the > > > > file is locked by WebDAV. > > > > > > > > } --Peter Zingg > > > > --Greg > > > > > > > > _______________________________________________ > > > > Rcalendar-devs mailing list > > > > Rcalendar-devs at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > > > > > > > > > > > > -- > > > ~~~~~~~~~~~~~~~~~~~ > > > David Andrew Thompson > > > http://dathompson.blogspot.com > > > > > > > > > -- > > ~~~~~~~~~~~~~~~~~~~ > > David Andrew Thompson > > http://dathompson.blogspot.com > > > > _______________________________________________ > > Rcalendar-devs mailing list > > Rcalendar-devs at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > > > > > -- > Ryan Thompson > ryan at rrt.ca > > -- > Ryan Thompson > ryan at rrt.ca > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > -- ~~~~~~~~~~~~~~~~~~~ David Andrew Thompson http://dathompson.blogspot.com From gsslist+rcal at anthropohedron.net Tue Feb 28 17:38:21 2006 From: gsslist+rcal at anthropohedron.net (Gregory Seidman) Date: Tue, 28 Feb 2006 17:38:21 -0500 Subject: [Rcalendar-devs] Fwd: Datastore formats In-Reply-To: <7b297ea20602281351i35ceee0cm4a1762d081291c1c@mail.gmail.com> References: <17112e2f0602280802t5f57c7d4j52223be02fddbc71@mail.gmail.com> <3E75F8CB-5448-45A7-B02B-BE2A986AF666@kentfieldschools.org> <20060228183735.GA28560@anthropohedron.net> <7b297ea20602281257v4dfff643x333b894bb9ad01d1@mail.gmail.com> <7b297ea20602281308n41cadc1an7d1ad1ce5613a48f@mail.gmail.com> <7b297ea20602281351i35ceee0cm4a1762d081291c1c@mail.gmail.com> Message-ID: <20060228223821.GA16037@anthropohedron.net> On Tue, Feb 28, 2006 at 01:51:45PM -0800, David Andrew Thompson wrote: } I completely agree...WebDAV functionality is a must. } } The main concern, in my mind, comes down to the ability to create a } WebDAV Controller to mitigate the protocol. If this is possible, we } can do whatever we want with the iCal Controller (even allowing for an } SVN alternative setting). } } It sounds as if Gregory might have a good understanding of the } protocol....How about it, Gregory....feel like writing the WebDAV } Controller? ;) Gee, I was just hoping to instigate it and have someone else do the implementation :-) I am much more familiar with using WebDAV than I am with the specifics of the protocol, but I think a WebDAV controller (or, more likely, module) is necessary for this. I'll start reading up on it and implement it. I expect that most of it will be delegated to hooks. } In the flowcharts (see previous email) I attempted to separate the } layers of concern (WebDAV/iCAL). I don't know if this is the best } solution, but it is a start. As I work on the WebDAV stuff I will see what kind of design I come up with. Certainly the chart at http://www.policorp.com/files/rcal/rCal_Flow.pdf is a good conceptual model, though it may not reflect the ultimate design. Also, it looks like we'll want to implement CalDAV, which seems to be a superset of WebDAV. More information can be found at http://ietf.webdav.org/caldav/home.html } Dave --Greg From gsslist+rcal at anthropohedron.net Tue Feb 28 17:43:54 2006 From: gsslist+rcal at anthropohedron.net (Gregory Seidman) Date: Tue, 28 Feb 2006 17:43:54 -0500 Subject: [Rcalendar-devs] Related to shared calendar datastore/WebDAV In-Reply-To: <604F245C-37BE-4254-89F7-F7A44806F76C@kentfieldschools.org> References: <604F245C-37BE-4254-89F7-F7A44806F76C@kentfieldschools.org> Message-ID: <20060228224354.GB16037@anthropohedron.net> On Tue, Feb 28, 2006 at 01:51:21PM -0800, Peter Zingg wrote: } Does anyone know if Apple's iCal (or other more group-oriented } clients, such as Outlook/Entourage, Mozilla or Evolution) have a } concept of a published calendar with multiple writers? This is what } my organization (a school district) is looking for. The typical use } case is an executive (our principal or superintendent) and an } appointment secretary. It would be great if both the exec and the } secretary could use a rich client like those mentioned above and } *publish changes to the same WebDAV ics file*. The Mozilla calendar extension, available at http://www.mozilla.org/projects/calendar/download.html is what I use. I run a WebDAV server at home and I share a calendar with my wife. Not what you'd call a high contention example, but it works nicely. I also use it from several difference machines, and all of them stay in sync without dropping anything, so that might be reassuring. Note that it is emphatically not release-quality. It's pretty solid, but its UI can be something of a hindrance. } This is what Apple is *not* doing with their "i" apps. It's publish } *or* subscribe, not both. Guess that why it's not called weCal. Yes. This is infuriating. } I assume there is enough meta-info in an ics file to determine how to } deal with conflicts, and WebDAV locks would help to keep things in sync. It's just the WebDAV lock. } Just something else for the wish list. } } Peter Zingg --Greg From greg.freemyer at gmail.com Tue Feb 28 18:48:45 2006 From: greg.freemyer at gmail.com (Greg Freemyer) Date: Tue, 28 Feb 2006 18:48:45 -0500 Subject: [Rcalendar-devs] WebDAV Message-ID: <87f94c370602281548p13cec29bw2eead551a22e9b9b@mail.gmail.com> On the other thread there is talk of writing a WebDAV plugin. Seems like the sort of thing we should try to find already existing. Unfortunately WebDAV support tends to be WebServer specific, but if we support the 3 most common servers (WEBrick, apache, lighttpd) that seems like it should suffice, at least at this early stage of the project. I just googled and found this solution which is specific to WEBrick: http://redhanded.hobix.com/inspect/webrickWebdavHandlerSafelyExtractedFromTheWild.html I know there are Apache modules that provide WebDAV. Lighttpd apparently has supported it for several months as well. See http://blog.lighttpd.net/articles/2005/08/22/lighttpd-1-4-1 So the question is if we can get by with a generic WebDAV solution, or do we really need a custom one? Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century From gsslist+rcal at anthropohedron.net Tue Feb 28 21:21:12 2006 From: gsslist+rcal at anthropohedron.net (Gregory Seidman) Date: Tue, 28 Feb 2006 21:21:12 -0500 Subject: [Rcalendar-devs] WebDAV In-Reply-To: <87f94c370602281548p13cec29bw2eead551a22e9b9b@mail.gmail.com> References: <87f94c370602281548p13cec29bw2eead551a22e9b9b@mail.gmail.com> Message-ID: <20060301022112.GA32096@anthropohedron.net> On Tue, Feb 28, 2006 at 06:48:45PM -0500, Greg Freemyer wrote: } On the other thread there is talk of writing a WebDAV plugin. } } Seems like the sort of thing we should try to find already existing. } Unfortunately WebDAV support tends to be WebServer specific, but if we } support the 3 most common servers (WEBrick, apache, lighttpd) that } seems like it should suffice, at least at this early stage of the } project. } } I just googled and found this solution which is specific to WEBrick: } } http://redhanded.hobix.com/inspect/webrickWebdavHandlerSafelyExtractedFromTheWild.html } } I know there are Apache modules that provide WebDAV. } } Lighttpd apparently has supported it for several months as well. } } See http://blog.lighttpd.net/articles/2005/08/22/lighttpd-1-4-1 } } So the question is if we can get by with a generic WebDAV solution, or } do we really need a custom one? All of these things provide a WebDAV interface to the filesystem. That is not what we need. We need to present a WebDAV interface to a database. } Greg --Greg From dandrew.thompson at gmail.com Tue Feb 28 21:43:54 2006 From: dandrew.thompson at gmail.com (David Andrew Thompson) Date: Tue, 28 Feb 2006 18:43:54 -0800 Subject: [Rcalendar-devs] WebDAV In-Reply-To: <20060301022112.GA32096@anthropohedron.net> References: <87f94c370602281548p13cec29bw2eead551a22e9b9b@mail.gmail.com> <20060301022112.GA32096@anthropohedron.net> Message-ID: <7b297ea20602281843y51be264fw92a4835ec1c79bef@mail.gmail.com> Gregory, You had mentioned writing some hooks to handle the WebDAV protocol. Any ideas on what the hooks might entail? Also, whereas webrick-webdav may not help, I discovered that it is possible to write servlets for the Webrick server. Here are a couple of links: http://microjet.ath.cx/WebWiki/WEBrick.html http://segment7.net/projects/ruby/WEBrick/servlets.html Do you know if it is possible to parse the WebDAV headers after Webrick processes the HTTP, or do we need to process them on the Webrick server layer? Dave On 2/28/06, Gregory Seidman wrote: > On Tue, Feb 28, 2006 at 06:48:45PM -0500, Greg Freemyer wrote: > } On the other thread there is talk of writing a WebDAV plugin. > } > } Seems like the sort of thing we should try to find already existing. > } Unfortunately WebDAV support tends to be WebServer specific, but if we > } support the 3 most common servers (WEBrick, apache, lighttpd) that > } seems like it should suffice, at least at this early stage of the > } project. > } > } I just googled and found this solution which is specific to WEBrick: > } > } http://redhanded.hobix.com/inspect/webrickWebdavHandlerSafelyExtractedFromTheWild.html > } > } I know there are Apache modules that provide WebDAV. > } > } Lighttpd apparently has supported it for several months as well. > } > } See http://blog.lighttpd.net/articles/2005/08/22/lighttpd-1-4-1 > } > } So the question is if we can get by with a generic WebDAV solution, or > } do we really need a custom one? > > All of these things provide a WebDAV interface to the filesystem. That is > not what we need. We need to present a WebDAV interface to a database. > > } Greg > --Greg > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -- ~~~~~~~~~~~~~~~~~~~ David Andrew Thompson http://dathompson.blogspot.com