[EMAIL PROTECTED] wrote:
<snip>
> 2. a VTODO object. Information about a TODO task.
Man... I will use this one :)
> 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.
Dude! That totally rocks. The cool thing is that if greater messaging
platforms start to support iCalendar JetSpeed can be pointed at
Microsoft Exchange to easy the migration towards OSS :)
> > 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
<snip>
>> 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
+1
> 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,
How do these objects map to XML? I would hope well. Any work here?
Now that Turbine authentication is setup it should be easy to have a XML
Document -> user persistence mechanism.
> > and
> > login
> > screens
Don't worry about login screens... JetSpeed handles this and you just
call this.getPortletConfig().getRunData().getUser()
> > 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.
How about XSP with a Portlet and as much logic kept outside the page. I
am going to start working on a logon screen as XSP and Mail:XSP
integration.
Kevin
--
Kevin A Burton
http://relativity.yi.org
Message to SUN: "Open Source Java!"
"For evil to win is for good men to do nothing."
--
--------------------------------------------------------------
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]
