From beattie.mark at gmail.com Sun Jan 15 23:53:54 2006 From: beattie.mark at gmail.com (Mark Beattie) Date: Mon, 16 Jan 2006 13:53:54 +0900 Subject: [Rcalendar-devs] webcalendar Message-ID: <200601161353.54130.beattie.mark@gmail.com> Hello all, I just stumbled across WebCalendar. It's an open source web scheduling app built in Perl, and seems to have a few features that rCalendar might be able to glean ideas from: http://www.ma.utexas.edu/webcalendar I'm just wondering, does anyone have any links to reference material on conflict resolution of recurring dates? What approach should rCalendar take? cheers, mark From gsslist+rcal at anthropohedron.net Mon Jan 16 14:57:11 2006 From: gsslist+rcal at anthropohedron.net (Gregory Seidman) Date: Mon, 16 Jan 2006 14:57:11 -0500 Subject: [Rcalendar-devs] WebDAV Message-ID: <20060116195709.GA11019@anthropohedron.net> I did a little Googling for Ruby and WebDAV. It appears that someone asked the Ruby list about something very similar (serving dynamic WebDAV content) almost a year and a half ago. The thread pretty much died out, though. On the other hand, I found the webrick-webdav RubyGem, which is a WEBrick servlet implementation of WebDAV (backed by the filesystem). It should be instructive for the protocol end of dynamic WebDAV content. I'm thinking that it might actually make sense to split off the WebDAV stuff into frontend and backend. I could imagine other people finding a dynamic WebDAV implementation useful if they could plug it into their apps. My main concern right now is whether it will integrate with RoR well. It may be necessary to run the WebDAV stuff as a servlet separate from the calendar RoR app. More investigation is warranted, but I thought I'd tell you folks about what I'd found so far. --Greg From dandrew.thompson at gmail.com Mon Jan 16 16:26:58 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Mon, 16 Jan 2006 13:26:58 -0800 Subject: [Rcalendar-devs] WebDAV In-Reply-To: <20060116195709.GA11019@anthropohedron.net> References: <20060116195709.GA11019@anthropohedron.net> Message-ID: <7b297ea20601161326u1e7415acr1a45406f82b3fe2e@mail.gmail.com> I would think that it makes sense to keep rCal a pluggable component for RoR, regardless of what container they are using, (WEBrick/or Apache,etc.) One of the difficulties inherent in WebDAV is the fact that it is a protocol and not an API. Dealing with protocols means discovering a manner to handle additional elements on the HTTP stack. An API would at least remove that added work and enable the software to not be dependent on the server/container environment. IMHO, it is a shame to have to depend on added stacks/protocols for calendaring. It would be amazing if we could provide the necessary locking/authoring via API enhanced database mechanisms (locking, committing, etc). I don't know if this is possible, but it sure would be a great move for the industry as a whole. It would then just be a matter of developing an client based API. I think that rCal for now should first focus on solving the immediate problem, namely that there is no pluggable web-based calendar solution. We can at least build out the solution with iCal governance. That way, should we choose to tackle the WebDAV/API layer, it will simply become a layer on the current specs. Being a graphics design guy (from my background) I like to figure out how the app will look in the end and then wrap the backend around that. With that in mind I have been looking at many different layouts out there and trying to discover one that I like the best. What are your thoughts? Here is a tentative list of potential spreads... phpCalendar http://www.sators.com/programming-phpcalendar.html imac's web-based calendar (my favorite) view attachments on rcal wiki https://opensvn.csie.org/traccgi/rcalendar/trac.cgi/wiki/calendar Regards, Dave On 1/16/06, Gregory Seidman wrote: > I did a little Googling for Ruby and WebDAV. It appears that someone asked > the Ruby list about something very similar (serving dynamic WebDAV content) > almost a year and a half ago. The thread pretty much died out, though. On > the other hand, I found the webrick-webdav RubyGem, which is a WEBrick > servlet implementation of WebDAV (backed by the filesystem). It should be > instructive for the protocol end of dynamic WebDAV content. > > I'm thinking that it might actually make sense to split off the WebDAV > stuff into frontend and backend. I could imagine other people finding a > dynamic WebDAV implementation useful if they could plug it into their apps. > My main concern right now is whether it will integrate with RoR well. It > may be necessary to run the WebDAV stuff as a servlet separate from the > calendar RoR app. > > More investigation is warranted, but I thought I'd tell you folks about > what I'd found so far. > > --Greg > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -- ~~~~~~~~~~~~~~~~~~~ D'Andrew "Dave" Thompson http://dathompson.blogspot.com From dandrew.thompson at gmail.com Mon Jan 16 18:03:53 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Mon, 16 Jan 2006 15:03:53 -0800 Subject: [Rcalendar-devs] WebDAV In-Reply-To: <7b297ea20601161326u1e7415acr1a45406f82b3fe2e@mail.gmail.com> References: <20060116195709.GA11019@anthropohedron.net> <7b297ea20601161326u1e7415acr1a45406f82b3fe2e@mail.gmail.com> Message-ID: <7b297ea20601161503i1c72468cic01869cde4f82103@mail.gmail.com> Just to clarify.... I think that the webDAV issue is a vital concern and would love to hear more on the implementation from those of you more experienced on the issue. Thanks, Dave On 1/16/06, D'Andrew Dave Thompson wrote: > I would think that it makes sense to keep rCal a pluggable component > for RoR, regardless of what container they are using, (WEBrick/or > Apache,etc.) > > One of the difficulties inherent in WebDAV is the fact that it is a > protocol and not an API. Dealing with protocols means discovering a > manner to handle additional elements on the HTTP stack. An API would > at least remove that added work and enable the software to not be > dependent on the server/container environment. > > IMHO, it is a shame to have to depend on added stacks/protocols for > calendaring. It would be amazing if we could provide the necessary > locking/authoring via API enhanced database mechanisms (locking, > committing, etc). I don't know if this is possible, but it sure would > be a great move for the industry as a whole. It would then just be a > matter of developing an client based API. > > I think that rCal for now should first focus on solving the immediate > problem, namely that there is no pluggable web-based calendar > solution. We can at least build out the solution with iCal governance. > That way, should we choose to tackle the WebDAV/API layer, it will > simply become a layer on the current specs. > > Being a graphics design guy (from my background) I like to figure out > how the app will look in the end and then wrap the backend around > that. With that in mind I have been looking at many different layouts > out there and trying to discover one that I like the best. > > What are your thoughts? > > Here is a tentative list of potential spreads... > > phpCalendar http://www.sators.com/programming-phpcalendar.html > imac's web-based calendar (my favorite) view attachments on rcal wiki > https://opensvn.csie.org/traccgi/rcalendar/trac.cgi/wiki/calendar > > Regards, > > Dave > > > On 1/16/06, Gregory Seidman wrote: > > I did a little Googling for Ruby and WebDAV. It appears that someone asked > > the Ruby list about something very similar (serving dynamic WebDAV content) > > almost a year and a half ago. The thread pretty much died out, though. On > > the other hand, I found the webrick-webdav RubyGem, which is a WEBrick > > servlet implementation of WebDAV (backed by the filesystem). It should be > > instructive for the protocol end of dynamic WebDAV content. > > > > I'm thinking that it might actually make sense to split off the WebDAV > > stuff into frontend and backend. I could imagine other people finding a > > dynamic WebDAV implementation useful if they could plug it into their apps. > > My main concern right now is whether it will integrate with RoR well. It > > may be necessary to run the WebDAV stuff as a servlet separate from the > > calendar RoR app. > > > > More investigation is warranted, but I thought I'd tell you folks about > > what I'd found so far. > > > > --Greg > > > > _______________________________________________ > > Rcalendar-devs mailing list > > Rcalendar-devs at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rcalendar-devs > > > > > -- > ~~~~~~~~~~~~~~~~~~~ > D'Andrew "Dave" Thompson > http://dathompson.blogspot.com > -- ~~~~~~~~~~~~~~~~~~~ D'Andrew "Dave" Thompson http://dathompson.blogspot.com From jc.michel at symetrie.com Mon Jan 16 18:07:59 2006 From: jc.michel at symetrie.com (Jean-Christophe Michel) Date: Tue, 17 Jan 2006 00:07:59 +0100 Subject: [Rcalendar-devs] WebDAV In-Reply-To: <7b297ea20601161503i1c72468cic01869cde4f82103@mail.gmail.com> References: <20060116195709.GA11019@anthropohedron.net> <7b297ea20601161326u1e7415acr1a45406f82b3fe2e@mail.gmail.com> <7b297ea20601161503i1c72468cic01869cde4f82103@mail.gmail.com> Message-ID: <43CC274F.20104@symetrie.com> Hi, D'Andrew "Dave" Thompson a ?crit : > Just to clarify.... > > I think that the webDAV issue is a vital concern and would love to > hear more on the implementation from those of you more experienced on > the issue. Thanks, Dave WOuldn't it be possible to have a real WebDav thing running, like svn 2.0 (remember, KIS) and have ruby scan for changed files (or better, have ahook be called by the webdav server each time a new file is received). Why reimplement in ruby a webdav server whereas there are already some good ones running ? -- Jean-Christophe Michel From ryan at rrt.ca Mon Jan 16 18:17:25 2006 From: ryan at rrt.ca (Ryan Thompson) Date: Mon, 16 Jan 2006 15:17:25 -0800 Subject: [Rcalendar-devs] WebDAV In-Reply-To: <43CC274F.20104@symetrie.com> References: <20060116195709.GA11019@anthropohedron.net> <7b297ea20601161503i1c72468cic01869cde4f82103@mail.gmail.com> <43CC274F.20104@symetrie.com> Message-ID: <200601161517.26130.ryan@rrt.ca> On Monday 16 January 2006 15:07, Jean-Christophe Michel wrote: > Hi, > > D'Andrew "Dave" Thompson a ?crit : > > Just to clarify.... > > > > I think that the webDAV issue is a vital concern and would love to > > hear more on the implementation from those of you more experienced on > > the issue. Thanks, Dave > > WOuldn't it be possible to have a real WebDav thing running, like svn > 2.0 (remember, KIS) and have ruby scan for changed files (or better, > have ahook be called by the webdav server each time a new file is > received). Why reimplement in ruby a webdav server whereas there are > already some good ones running ? If I remember correctly, this is how I used svn with phpicalendar. I setup a normal svn repo. Then I created a calendar file like so for each user like https://hostname/trunk/calendar/username.ics. The phpicalendar webapp references the svn URI for it's calendar source. It worked nicely. Ryan From alang at cronosys.com Tue Jan 17 08:25:12 2006 From: alang at cronosys.com (Alan Garrison) Date: Tue, 17 Jan 2006 08:25:12 -0500 Subject: [Rcalendar-devs] Existing web calendar apps Message-ID: <43CCF038.9050603@cronosys.com> (Just joined the list, this is basically an addendum to Mark Beattie's email) The Horde project (PHP framework) has a fairly good web calendar app with pluggable backends and iCal support: http://www.horde.org The calendar app is called "kronolith", so just throwing another thing out there to look at... -- Alan Garrison Cronosys, LLC Phone: 216-221-4600 ext 308 From dandrew.thompson at gmail.com Wed Jan 18 15:16:06 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Wed, 18 Jan 2006 12:16:06 -0800 Subject: [Rcalendar-devs] SVN repository Message-ID: <7b297ea20601181216y71c01aah745761ae255c0be1@mail.gmail.com> Is there anyone out there that feels like managing the svn repository? Namely the setup and administration, release bundling, tagging, etc.? I can add you as an administrator. I am currently using OpenSVN as the host site (which also provides the trac interface). Thanks, Dave -- ~~~~~~~~~~~~~~~~~~~ D'Andrew "Dave" Thompson http://dathompson.blogspot.com From ryan at rrt.ca Wed Jan 18 16:29:43 2006 From: ryan at rrt.ca (Ryan Thompson) Date: Wed, 18 Jan 2006 13:29:43 -0800 Subject: [Rcalendar-devs] SVN repository In-Reply-To: <7b297ea20601181216y71c01aah745761ae255c0be1@mail.gmail.com> References: <7b297ea20601181216y71c01aah745761ae255c0be1@mail.gmail.com> Message-ID: <200601181329.43942.ryan@rrt.ca> I can do that. Ryan On Wednesday 18 January 2006 12:16, D'Andrew "Dave" Thompson wrote: > Is there anyone out there that feels like managing the svn repository? > Namely the setup and administration, release bundling, tagging, etc.? > > I can add you as an administrator. I am currently using OpenSVN as the > host site (which also provides the trac interface). > > Thanks, > > Dave > > -- > ~~~~~~~~~~~~~~~~~~~ > D'Andrew "Dave" Thompson > http://dathompson.blogspot.com > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs From dandrew.thompson at gmail.com Thu Jan 19 15:33:55 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Thu, 19 Jan 2006 12:33:55 -0800 Subject: [Rcalendar-devs] Database and/or ics Flat Files Message-ID: <7b297ea20601191233t380ddcc8p13d136c89576fd24@mail.gmail.com> I would appreciate your input on the question of the model schema we should use. A couple of possibilities. 1. Persist the data by way of ics flat files, either via SVN, or in some other directory on the server. Benefit would be the speed of simply using and iterating over a flat file. Loss would be the difficulty in accessing data across an application using rcalendar. 2. Persist the data by way of a database and create the ics files on the fly. Benefit to this is the ability to utilize the schema's data in any of the other application's needs directly from the database. Loss would be the time it takes to generate the ics files on the fly. What are your thoughts? -- ~~~~~~~~~~~~~~~~~~~ D'Andrew "Dave" Thompson http://dathompson.blogspot.com From doug at lathi.net Thu Jan 19 15:40:51 2006 From: doug at lathi.net (Doug Alcorn) Date: Thu, 19 Jan 2006 15:40:51 -0500 Subject: [Rcalendar-devs] Database and/or ics Flat Files In-Reply-To: <7b297ea20601191233t380ddcc8p13d136c89576fd24@mail.gmail.com> References: <7b297ea20601191233t380ddcc8p13d136c89576fd24@mail.gmail.com> Message-ID: On Jan 19, 2006, at 3:33 PM, D'Andrew Dave Thompson wrote: > 2. Persist the data by way of a database and create the ics files on > the fly. Benefit to this is the ability to utilize the schema's data > in any of the other application's needs directly from the database. > Loss would be the time it takes to generate the ics files on the fly. Definitely this option. Your goal as a Rails developer is to stay on the golden path as much as it makes sense. Using ActiveRecord for your data is best from that standpoint. Particularly if this is a plugin. ----- Doug Alcorn (513) 295-2844 doug at lathi.net http://www.lathi.net/ From dandrew.thompson at gmail.com Thu Jan 19 15:55:49 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Thu, 19 Jan 2006 12:55:49 -0800 Subject: [Rcalendar-devs] Database and/or ics Flat Files In-Reply-To: References: <7b297ea20601191233t380ddcc8p13d136c89576fd24@mail.gmail.com> Message-ID: <7b297ea20601191255l2288a7aeta11f2e655c7ede99@mail.gmail.com> Presuing the database persistence, what shall we say for the storyboard for a web client? 1. User navigates to calendar view. 2. triggered by a tag in the view layer, the controller accesses calendar model which retrieves the data from the db and returns it as an ics file. 3. contoller maps a call to iterate over the ics file and return the data in a view output based upon the view choice made by client - month, week, day Naturally if we should want to allow WebDAV interfacing we would need to figure out a way to sync the db data with the SVN repository, should that be the choice. What do you think? Dave On 1/19/06, Doug Alcorn wrote: > > On Jan 19, 2006, at 3:33 PM, D'Andrew Dave Thompson wrote: > > > 2. Persist the data by way of a database and create the ics files on > > the fly. Benefit to this is the ability to utilize the schema's data > > in any of the other application's needs directly from the database. > > Loss would be the time it takes to generate the ics files on the fly. > > Definitely this option. Your goal as a Rails developer is to stay on > the golden path as much as it makes sense. Using ActiveRecord for > your data is best from that standpoint. Particularly if this is a > plugin. > ----- > Doug Alcorn > (513) 295-2844 > doug at lathi.net > http://www.lathi.net/ > > > -- ~~~~~~~~~~~~~~~~~~~ D'Andrew "Dave" Thompson http://dathompson.blogspot.com From dandrew.thompson at gmail.com Fri Jan 20 20:08:42 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Fri, 20 Jan 2006 17:08:42 -0800 Subject: [Rcalendar-devs] Rails Engine & SNV Repository Message-ID: <7b297ea20601201708q171b04bfgedb675d0935bd7ff@mail.gmail.com> I have been reading over engines vs plugins vs components. Good comparison at http://rails-engines.org/wiki/pages/Components+vs.+Plugins+vs.+Engines It would appear that rCalendar would be better suited as an engine which would better enable far more functionality. So on the SVN end of things what do you think of the following structure: APPLICATION/ - folder where we can keep the pre-extracted-engine application (the full rails application structure) TRUNK/ - folder where we can keep the extracted engine for development TAGS/ - tagged releases of engine (probably 0.1 to start) BRANCHES/ - braches of engine Thoughts? Dave -- ~~~~~~~~~~~~~~~~~~~ D'Andrew "Dave" Thompson http://dathompson.blogspot.com From greg.freemyer at gmail.com Tue Jan 31 12:30:00 2006 From: greg.freemyer at gmail.com (Greg Freemyer) Date: Tue, 31 Jan 2006 12:30:00 -0500 Subject: [Rcalendar-devs] rCal now targeting an engine format Message-ID: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> I see that the wiki was updated to show rCal now targeting a engine structure. Has it been discussed if it will be compatible with the login and user engines? My personal hope is that it will be, but I don't know any of the technical issues associated with that hope. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century From dandrew.thompson at gmail.com Tue Jan 31 15:18:08 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Tue, 31 Jan 2006 12:18:08 -0800 Subject: [Rcalendar-devs] rCal now targeting an engine format In-Reply-To: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> References: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> Message-ID: <7b297ea20601311218s1cceddfeu5ca3d387bfdb100f@mail.gmail.com> Greg, Thank you for the email. Whereas we have just begun the project, we are certainly open to new suggestions and potential features/intergrations. Your input would be very much appreciated. No one has actually thought of such an integration, to my knowledge. It may make sense to work on that ability. If you, or anyone else, knows of a way to integrate the two engines efficiently, let me know. Currently I have finished an intial layout for the month view of the calendar layout. I will post a pic as well as a zip of the html/css as soon as I can (next few days). Once we've come to an agreed upon layout and have worked out the html/css bugs, we can begin translating that into railese. Dave -- ~~~~~~~~~~~~~~~~~~~ D'Andrew "Dave" Thompson http://dathompson.blogspot.com On 1/31/06, Greg Freemyer wrote: > > I see that the wiki was updated to show rCal now targeting a engine > structure. > > Has it been discussed if it will be compatible with the login and user > engines? > > My personal hope is that it will be, but I don't know any of the > technical issues associated with that hope. > > Greg > -- > Greg Freemyer > The Norcross Group > Forensics for the 21st Century > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rcalendar-devs/attachments/20060131/dde02d30/attachment.htm From greg.freemyer at gmail.com Tue Jan 31 16:33:33 2006 From: greg.freemyer at gmail.com (Greg Freemyer) Date: Tue, 31 Jan 2006 16:33:33 -0500 Subject: [Rcalendar-devs] rCal now targeting an engine format In-Reply-To: <7b297ea20601311218s1cceddfeu5ca3d387bfdb100f@mail.gmail.com> References: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> <7b297ea20601311218s1cceddfeu5ca3d387bfdb100f@mail.gmail.com> Message-ID: <87f94c370601311333h6850a95eg86d0bfe4a668d84@mail.gmail.com> On 1/31/06, D'Andrew Dave Thompson wrote: > Greg, > > Thank you for the email. > > Whereas we have just begun the project, we are certainly open to new > suggestions and potential features/intergrations. Your input would be very > much appreciated. > > No one has actually thought of such an integration, to my knowledge. It may > make sense to work on that ability. If you, or anyone else, knows of a way > to integrate the two engines efficiently, let me know. > > Currently I have finished an intial layout for the month view of the > calendar layout. I will post a pic as well as a zip of the html/css as soon > as I can (next few days). Once we've come to an agreed upon layout and have > worked out the html/css bugs, we can begin translating that into railese. > > Dave Dave, I'm not positive but I think the main thing up front would be to ensure the schema for rCal is an extension of the schema for the login and user engines. I.e. the login engine has a very simple schema: 1 table (of users) with 15 fields. I have not worked with the user engine yet, so I'm not sure how it extends the above schema. If you want to have the login engine and rCal engine to work together then it would make the most sense for rCal to either add columns to the users table or to setup one-to-one and one-to-many relationships between the users table and the rCal tables. ie. The users table already has the login name, e-mail address, first name, last name. It would be most efficient if the rCal engine could build on login engine's user table for these fields. (fyi, none of the other user fields seem relevant to rCal to me.) The negative with this approach is that the login engine now becomes a prereq. to the rCal engine, or at least the "users" table does. For me personally that is not a problem but it may be on a broader set of users. FYI: The user engine (as opposed to the login engine) establishes user roles and capabilities. So if rCal is going to have the concept of an admin that can modify anybody's calendar entries then it wold make sense to use/extend the user engine. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century From jc.michel at symetrie.com Tue Jan 31 17:10:38 2006 From: jc.michel at symetrie.com (Jean-Christophe Michel) Date: Tue, 31 Jan 2006 23:10:38 +0100 Subject: [Rcalendar-devs] rCal now targeting an engine format In-Reply-To: <87f94c370601311333h6850a95eg86d0bfe4a668d84@mail.gmail.com> References: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> <7b297ea20601311218s1cceddfeu5ca3d387bfdb100f@mail.gmail.com> <87f94c370601311333h6850a95eg86d0bfe4a668d84@mail.gmail.com> Message-ID: <43DFE05E.90907@symetrie.com> Greg Freemyer a ?crit : > I'm not positive but I think the main thing up front would be to > ensure the schema for rCal is an extension of the schema for the login > and user engines. ... > > If you want to have the login engine and rCal engine to work together > then it would make the most sense for rCal to either add columns to > the users table or to setup one-to-one and one-to-many relationships > between the users table and the rCal tables. Hey, I don't think we should think to the schema uniquely under this compatibility. > The negative with this approach is that the login engine now becomes a > prereq. to the rCal engine, or at least the "users" table does. For > me personally that is not a problem but it may be on a broader set of > users. Exactly. I want to use active_rbac to have fine grained permissions. > FYI: The user engine (as opposed to the login engine) establishes user > roles and capabilities. So if rCal is going to have the concept of an > admin that can modify anybody's calendar entries then it wold make > sense to use/extend the user engine. I think rcal can rely on a User object with some basic properties, but should bot tie to deeply to one system. Then we'll add howtos on the wiki to explain our solutions with each engine. -- Jean-Christophe Michel Sym?trie, ?dition de musique et services 30 rue Jean-Baptiste Say 69001 LYON (FRANCE) +33 (0)478 29 52 14 +33 (0)478 30 01 11 "We must learn to live together as brothers or perish together as fools." Martin Luther King, Jr. From dandrew.thompson at gmail.com Tue Jan 31 20:10:26 2006 From: dandrew.thompson at gmail.com (D'Andrew "Dave" Thompson) Date: Tue, 31 Jan 2006 17:10:26 -0800 Subject: [Rcalendar-devs] rCal now targeting an engine format In-Reply-To: <43DFE05E.90907@symetrie.com> References: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> <7b297ea20601311218s1cceddfeu5ca3d387bfdb100f@mail.gmail.com> <87f94c370601311333h6850a95eg86d0bfe4a668d84@mail.gmail.com> <43DFE05E.90907@symetrie.com> Message-ID: <7b297ea20601311710i19529128r3113f2bd81f54fc@mail.gmail.com> My first inclination is to not include any user/roles in the base release. That way we can provide a stripped down version of the rCal engine for those who want to work their own RBAC(Role-Based Access Control). We can later work on a complete system rCal which includes an RBAC solution. I think that this would be beneficial to many users who simply want a calendar program. I haven't had the time to research any particular RBAC yet (login/user engines, or other). Although it certainly would be great to have all of you chime in on your opinions as to which RBAC to use. Thanks for the insight, everyone. Dave On 1/31/06, Jean-Christophe Michel wrote: > > Greg Freemyer a ?crit : > > I'm not positive but I think the main thing up front would be to > > ensure the schema for rCal is an extension of the schema for the login > > and user engines. > ... > > > > If you want to have the login engine and rCal engine to work together > > then it would make the most sense for rCal to either add columns to > > the users table or to setup one-to-one and one-to-many relationships > > between the users table and the rCal tables. > > Hey, I don't think we should think to the schema uniquely under this > compatibility. > > > The negative with this approach is that the login engine now becomes a > > prereq. to the rCal engine, or at least the "users" table does. For > > me personally that is not a problem but it may be on a broader set of > > users. > > Exactly. I want to use active_rbac to have fine grained permissions. > > > FYI: The user engine (as opposed to the login engine) establishes user > > roles and capabilities. So if rCal is going to have the concept of an > > admin that can modify anybody's calendar entries then it wold make > > sense to use/extend the user engine. > > I think rcal can rely on a User object with some basic properties, but > should bot tie to deeply to one system. > Then we'll add howtos on the wiki to explain our solutions with each > engine. > > -- > Jean-Christophe Michel > > Sym?trie, ?dition de musique et services > 30 rue Jean-Baptiste Say > 69001 LYON (FRANCE) > +33 (0)478 29 52 14 > +33 (0)478 30 01 11 > > "We must learn to live together as brothers > or perish together as fools." > Martin Luther King, Jr. > _______________________________________________ > 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/20060131/b02377e7/attachment-0001.htm From doug at lathi.net Tue Jan 31 20:15:22 2006 From: doug at lathi.net (Doug Alcorn) Date: Tue, 31 Jan 2006 20:15:22 -0500 Subject: [Rcalendar-devs] rCal now targeting an engine format In-Reply-To: <7b297ea20601311710i19529128r3113f2bd81f54fc@mail.gmail.com> References: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> <7b297ea20601311218s1cceddfeu5ca3d387bfdb100f@mail.gmail.com> <87f94c370601311333h6850a95eg86d0bfe4a668d84@mail.gmail.com> <43DFE05E.90907@symetrie.com> <7b297ea20601311710i19529128r3113f2bd81f54fc@mail.gmail.com> Message-ID: On Jan 31, 2006, at 8:10 PM, D'Andrew Dave Thompson wrote: > My first inclination is to not include any user/roles in the base > release. That way we can provide a stripped down version of the > rCal engine for those who want to work their own RBAC(Role-Based > Access Control). > > We can later work on a complete system rCal which includes an RBAC > solution. I agree that a calendaring engine doesn't need to include users at all. That's the simplest thing that could possibly work. ----- Doug Alcorn (513) 295-2844 doug at lathi.net http://www.lathi.net/ From pzingg at kentfieldschools.org Tue Jan 31 23:06:47 2006 From: pzingg at kentfieldschools.org (Peter Zingg) Date: Tue, 31 Jan 2006 20:06:47 -0800 Subject: [Rcalendar-devs] rCal now targeting an engine format In-Reply-To: References: <87f94c370601310930u7d12859bw37996e53d3f4df8a@mail.gmail.com> <7b297ea20601311218s1cceddfeu5ca3d387bfdb100f@mail.gmail.com> <87f94c370601311333h6850a95eg86d0bfe4a668d84@mail.gmail.com> <43DFE05E.90907@symetrie.com> <7b297ea20601311710i19529128r3113f2bd81f54fc@mail.gmail.com> Message-ID: <875D3DF6-AA1B-4CC7-AC32-BF817AE73E1B@kentfieldschools.org> Depending on the time frame desired to produce the rCal engine, I would disagree. For me calendaring is inseparable from user- and group-awareness. Sharing of calendars and events, invitees, etc., is the main thing that my organization is interested in. If you need to eliminate the dependency on another engine, there should be at least stubs or directives that relate to whether a principal (some abstraction of a user or group) has particular rights to view or edit an event or a calendar as a whole. Take a look at SchoolTool to see how they use Zope's RBAC to add views of shared calendars to a user's calendar. Just my 2 cents. Peter Zingg Kentfield School District On Jan 31, 2006, at 5:15 PM, Doug Alcorn wrote: > > On Jan 31, 2006, at 8:10 PM, D'Andrew Dave Thompson wrote: > >> My first inclination is to not include any user/roles in the base >> release. That way we can provide a stripped down version of the >> rCal engine for those who want to work their own RBAC(Role-Based >> Access Control). >> >> We can later work on a complete system rCal which includes an RBAC >> solution. > > I agree that a calendaring engine doesn't need to include users at > all. That's the simplest thing that could possibly work. > ----- > Doug Alcorn > (513) 295-2844 > doug at lathi.net > http://www.lathi.net/ > > > _______________________________________________ > Rcalendar-devs mailing list > Rcalendar-devs at rubyforge.org > http://rubyforge.org/mailman/listinfo/rcalendar-devs >