commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Periodicity requirements & design
Date Mon, 04 Mar 2002 01:16:26 GMT

    I'm helping on Periodicity with some small things, like testing and a
Time Zone implementation.  I believe that a discussion and development of a
complete set of requirements for Periodicity would be a great thing.  The
project will grow fastest and best when its goals meet the needs of a group
of interested and involved people.

    A few days ago, the main committer on this project, Jeff Prickett,
offered the following to a couple of interested developers:
"Where we are is we have the basic design of the iCalendar objects
"implemented. We need code to save the objects to a database, templates in
"Velocity to view them in a web browser, security integration with Turbine
"and JAAS. After that we should be ready for a 0.0.1 release.
"I look forward to working with you and hope that you decide to
"join us as we build a world class calendaring application.

    While this is definitely not a complete set of requirements, it does
outline an absolute minimum set of capabilities that must be implemented for
Periodicity to function.  Additional core features, enhancements, and
yet-to-be-identified critical components must be added.

In your email, you said:
> How are we going about to formalize the requirements
> and the design of this wonderful new system?

I look forward to working with you.

Bottom line: Thanks for taking the time to look at Periodicity.  Please

    Personal note:  I am new to Jakarta and fairly new to programming.  I
appreciate you taking the time to include links to relevant documents in
your email.  I have downloaded the Palen dissertation and a Meeting
Scheduler paper from the KAOS site and plan to read them over the next week.


Mike George

----- Original Message -----
From: "Peter Odéus" <>
To: "periodicity jakarta" <>
Sent: Sunday, March 03, 2002 4:39 PM
Subject: Periodicity requirements & design

> Hi
> Calendars/address books are somewhat trivialized when
> it comes to implementing an electronical one. Due to
> the fact that we all seem to know what a calendar is
> (I cannot back that up, just taking a wild guess ;-)),
> there is a danger in simply copying the paper calendar
> artifacts and transferring them to electronic media,
> not thinking too much about the new questions that are
> implicitly raised by doing that.
> Security and privacy questions are not the only ones.
> The little research e.g.[Palen] that has been done in
> the area, show that people need several convincing
> features in order to commit to the new calendar
> artifact, and eventually dispose the old one (why give
> up the trusty old paper-, brain- or no calendar if the
> new one does not give me a higher added value).
> The new electronical calendar artifact is definitely
> promising. The only problem is to reach a sufficient
> state of mind-sharing in order to reveal all those
> goodies (and issues). Before finishing the coding.
> So...
> How are we going about to formalize the requirements
> and the design of this wonderful new system? Maybe
> goal-oriented requirements engineering [KAOS] and UML?
> Ideas, anyone?
> [KAOS]
> kind regards,
> Peter Odéus
> _____________________________________________________
> Hitta snörapporter...
> från 500 olika skidorter i Europa
> på
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message