[geeklog-devel] GSoC Calendar Plugin

[Vincent Furia]

This is a long one responding to many of the points in this thread so far.
Please forgive the "wrap up" nature of the email, but I thought it would be
easier to follow in this way.

Looks good. It's quite a bundle, though.

The more I consider what all is involved, the more I think it may be too
much to implement over the course of GSoC.

 We should probably break down the list into "must have", "nice to have",
> and something in between.

A good idea, though the design will have to take all "must haves" and "nice
to haves" into account so the "nice to haves" can be incorporated at a later
date without creating spaghetti code. I'll get around this weekend to
breaking up the "requirements" into a "must haves" and "should design for
future features to include..." lists.

Surely there are calendar scripts or classes out there that could be re-used
> or salvaged. What's our position on using someone else's code to achieve
> (possibly large) portions of this goal? Apart from the obvious license
> issues, of course.
>
I thought that was one of the best points of the GPL: Code reuse. I think it
would be great to use existing calendar classes/templates or whatever we can
find. There will be plenty of work integrating it into Geeklog (and
potentially with SocNet). I'll add that as well to the wiki. One caveat is
that the any "reuse" code should be identified before the coding period
starts. I don't think we want the coding period tied up selecting between
different libraries to use for the implementation.

Any socnet capabilities for this plugin revamp?
>

The problem is, they will both be developed at the same time (hopefully).
> This means the mentors/students should work together to hammer out the
> designs where they cross paths. There is no need for the new Calendar plugin
> to have to worry about creating/editing/deleting group/friends. These
> controls should be supplied by SocNet.
>
As I said before, we'll definitely want to keep SocNet in mind during the
design.  I would hate to cause the student working on the Calendar to be
dependent on the student working on SocNet. What happens if SocNet undergoes
a major design change halfway through? Or what if the student working on
SocNet washes out? What happens if we don't get any good student
applications for SocNet? Basically, I don't think we should make this
project (or any other) dependent on other projects.

Google Calendar has an API for a calendar service (
> http://code.google.com/apis/calendar/) that could potentially be hooked
> into by Geeklog. I worked with it on a personal project, and it seemed quite
> user friendly.
>
I really like Google Calendar (and their API looks great). But for a "core"
plugin I don't think we should have a dependency on an outside web service.
I did place in the "requirements" the ability to sync with Google Calendar
(along with other web based calendar services), but that probably falls
under the "nice to have" category.

Rewriting from scratch is probably the best part of this idea. (It's what I
> should have done a couple years ago for the bounty.) However, rewriting from
> scratch adds a lot extra time to the project as well. I would call these
> requirements beyond ambitious. 3 months is not enough time to tackle even a
> 1/3 of all the stuff listed.
>
I think having "group" calendars and multiple user calendars is premature
> without the core group upgrades we've been discussing. When paring down the
> requirements I would look toward this part as "design for it but don't worry
> about getting it in".
>
I agree on all points.

So there's no desire to take the calendar upgrade I wrote into the core
> calendar? It has reminders and subscriptions already.
>
Joe, I'm sorry to say I don't remember this. Though as you said, a rewrite
is needed for our Calendar.

The problem is, they will both be developed at the same time (hopefully).
> This means the mentors/students should work together to hammer out the
> designs where they cross paths. There is no need for the new Calendar plugin
> to have to worry about creating/editing/deleting group/friends. These
> controls should be supplied by SocNet.
>
Tom, I think I addressed this above.  Let me know if I missed a point.

While personally I rather see us concentrate on other parts of Geeklog as we
> already have a Calendar plugin (I know it has its issues) I do think this
> project could be a great tie in for SocNet.
>
I brought up the calendar idea because we were a little short of project
ideas, and this is one that has bothered me for a long time. I think Dirk's
still looking for more ideas for the Summer.

-Vinny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20100225/a2d0ae7d/attachment.html>