On Sat, 12 Feb 2000, Stephen Adkins wrote:
> BACKGROUND
>
> It sounds like Jeff has done a lot with calendaring
> and Sandy has done a lot with project/task management.
> Jeff suggested a new package that his calendar code would
> be in and has volunteered to help additionally on Turbine-
> integration with Sandy's code.
>
Yes, I am attepmting to get Tomcat, Jetspeed, and Sandy's code running on
my development box.
Some background on iCalendar objects for those who dont know.
iCalendar is an internet rfc, rfc2445. It defines a standard set of
"business" objects for sharing calendar information between clients. It,
also defines a format for "serializing" those objects into an ASCII text
stream which is its primary purpose.
It defines:
1. a VEVENT object. An object that describes an appointment or
event.
2. a VTODO object. Information about a TODO task.
3. a VJOURNAL object. A journal object about something that happened in
the past.
4. VFREEBUSY object. Information about when a person is free or busy, used
primarily to plan meetings.
5. VTIMEZONE object. Information about a time zone
These are business objects and say nothing about presentation. The
presentation could be a web based client (read Jetspeed, based on Sandy's
code) or they could be a fat client like Outlook, Netscape Calendar, or
KDE's KOrganizer.
If you want to see an iCalendar object stream look at the file saved by
KOrganizer. KOrganizer in KDE saves its data in iCalendar format. It will
provide a good testing tool for our iCalendar implementation.
Where the code is at.
I began the code from the bottom up and have implemented most of the
primitive data types (ie date time, time, duration, etc).
<snip>
>
> However, in the longer term, I would propose that the package
> structure (and the identification of business object classes)
> be driven by a bigger vision of where the functionality is going.
> (i.e. The design should be driven by a statement of the
> functional requirements. what a concept...) ;-)
>
I agree
> I would volunteer to produce and maintain such a functional
> requirements document, unless someone else who has more history
> with this project would like to do it or unless someone thinks
> this is a bad idea. I would clearly need contributions from
> all of you who have ideas already of what the requirements are
> (and what requirements/features the code already implements).
>
A good place to start would be the rfc for iCalendar. There are related
protocols and standards to this that we need to account for. I am in the
process of putting together a web page for the initial code drop to
Apache. It should be ready by tomorrow afternoon
> I would probably start by collecting what is already implemented,
> add the essential requirements satisfied by MS Outlook, and
> then add some of my own ideas that I have a particular interest
> in helping implement.
>
> As far as conventions go, the members of the Turbine list have
> been discussing a reorganization of the packages within Turbine
> to reflect that some of the classes actually implement business
> objects, and they should go in a "logical package" (think UML)
> under an "om" (object model) package. A subset of the proposed
> Turbine packages is listed below.
>
> org.apache.turbine.om
> org.apache.turbine.om.peer
> org.apache.turbine.om.user
> org.apache.turbine.om.user.peer
> org.apache.turbine.om.security
> org.apache.turbine.om.security.peer
> org.apache.turbine.util
> org.apache.turbine.util.db
>
> Perhaps a standard for Turbine applications could be to include
> the following package structure.
>
> org.apache.<appname>.om
> org.apache.<appname>.om.<logicalpackage>
> org.apache.<appname>.om.<logicalpackage>.peer
> org.apache.<appname>.util
> org.apache.<appname>.util.db
>
> In this spirit, the project management and calendaring functionality
> might be integrated into the following package structure.
>
> org.apache.jetspeed.om
> org.apache.jetspeed.om.project
> org.apache.jetspeed.om.project.peer
> org.apache.jetspeed.om.calendar
> org.apache.jetspeed.om.calendar.peer
> org.apache.jetspeed.util
> org.apache.jetspeed.util.db
>
> (Or maybe calendaring is in fact part of the "project" package.)
>
Above is a good first cut at the problem, but I would make two minor
changes to the layout. top-level would be project.
org.apache.jetspeed.project.icalendar - My iCalendar implementation
org.apache.jetspeed.project.presentation - Sandy's project code
org.apache.jetspeed.project.util - Utility classes to support calendaring
I have taken out the OM portion as there has been some discussion on
Turbine that om is too generic to be descriptive. I think it works better
in turbine because the objects are more generic, here they are specific.
I think project is descriptive enough. I have removed the dependencies on
peer classes because hopefully we can use OPL as it matures.
> Hopefully the utilities classes, persistence mechanisms, and login
> screens can all eventually be rethought over time as part of
> Turbine integration.
>
> P.S. Jeff, I think that the "calendaring client" that you mention
> below (if it is servlet/HTML-based) is certainly not too ambitious
> for the project.
>
> Stephen
>
<snip>
Jeff Prickett
[EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
