Peter,
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.
<snip>
"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
contribute.
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.
Thanks,
Mike George
----- Original Message -----
From: "Peter Od�us" <[EMAIL PROTECTED]>
To: "periodicity jakarta" <[EMAIL PROTECTED]>
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?
>
> REFERENCES
>
> [KAOS]http://www.info.ucl.ac.be/research/projects/AVL/ReqEng.html
>
> [PALEN]http://www.cs.colorado.edu/~palen/dissertation/LPdissertation.pdf
>
> kind regards,
>
> Peter Od�us
>
>
> _____________________________________________________
> Hitta sn�rapporter...
> fr�n 500 olika skidorter i Europa
> p� http://se.snow.yahoo.com
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
