Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Sun, 24 Feb 2002 04:16:42 -0500 (EST)
From: Jeff Prickett <prickett@shpimp.com>
To: commons-dev@jakarta.apache.org
Subject: Re: Periodicity requirements & design (fwd)
Message-ID: <Pine.LNX.4.44.0202240416110.4453-100000@dhcp-23-424>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE


My apologies if this is coming across the list twice. I dont see it in the=
=20
archives and I sent it and never received it back from the list.

---------- Forwarded message ----------
Date: Mon, 4 Mar 2002 06:15:05 -0600 (CST)
From: Jeff Prickett <prickett@www1.kc.aoindustries.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: Periodicity requirements & design

On Mon, 4 Mar 2002, Peter Od=E9us wrote:

>=20
> I agree. Sharing is probably one of the most important
> things (at least in the business area). "Browse me"
> might eventually be the standard answer to the
> question "do you have time to see me next week?".
> Moreover, an important aspect of sharing is the
> default "openness" setting of the system, because
> users tend not to change default settings [Palen]. But
> maybe sharing is less important for people managing
> their personal, non-business part of the calendar. Who
> knows?
>

You are correct that users dont tend to change the default settings. By=20
default sharing should be a relatively painless process.
=20
> Event reminders and the ability to tailor
> sophisticated recurring events also seem to be crucial
> according to [Palen].
>=20

Recurring events are tough to get right in just about every aspect. They=20
can get extremely complicated. Luckily we have not implemented handling=20
for recurring events just yet so we have not made any mistakes :).

> My personal thoughts include, but are not limited to:
> -Heavily localized information (dates etc.)
> -Tight integration between the rolodex/address book
> (vCards)and the calendar. My theory is that two pieces
> of data could relate intimately to each other, where
> one piece pertains to time (workout class schedule)
> while the other is fairly static (gym phone number).
> In those cases it might be important to be able to
> make such a strong two-way connection. (The gym
> publishing its workout schedule is an example of a
> [SKiCal] event, by the way.)

Good point. Again we have not quite gotten that far yet so we probably are=
=20
ok. Tight integration with vCard would be great. Interactions between=20
SkiCal also need a lot of research. It could be that we could just use the=
=20
mechanisms outlined in RFC 2446, but I cant say that for sure because I=20
have not read RFC2446 or SKiCal thoroughly yet.

> -Dynamic rolodex in the sense that e.g. an address is
> made non-atomic, which means that a phone number can
> be intimately related to the address. =20
>=20
>=20
> I would be glad to give it a shot, even though I am
> currently more of an HCI novice than an expert. A lot
> of pointers are to be collected from [Palen], though.
>

We could start there. I downloaded it last night. It is a pretty hefty=20
document and I am sure that we could learn a lot from it. As far as not=20
being an HCI expert, thats ok. This is Open Source, we work on what we=20
like even if we are not "experts". At work or in college you program what=
=20
other people want you to. Here people program on what interests them. I=20
suggested the HCI part for you because you seemed to have an interest.

One of my jobs as "leader" is to get people who are interested in=20
iCalendar working on the part that interests them the most while ensuring=
=20
that the project as a whole moves along.=20
=20
> > Jeff Prickett:
> > ...=20
> > If you would like to pick up the torch for the use
> > case analysis it would=20
> > be greatly appreciated
>=20
> The goals of the system must be carefully elaborated
> (e.g. [KAOS]), and as you point out, a proper use case
> analysis must be done. But since I am an absolute
> beginner in these areas, there is obviously a need for
> an expert discussion partner. Anybody out there?
>=20

I will be available for discussion and can advise you on use case=20
analysis. Furthermore, if we get enough semi-intelligent discussions going=
=20
other experts who may be listening may jump in and add valuable=20
information. I will read some of the KAOS research and we can continue the=
=20
discussions.

You will not be expected to shoulder the requirements analysis alone. I=20
think that you could play an invaluable role in coordinating the=20
requirements analysis. You could follow along with the discussions and=20
maintain a use case document. If you need help with use case analysis we=20
will help.

> REFERENCES
>=20
> [KAOS]http://www.info.ucl.ac.be/research/projects/AVL/ReqEng.html
>=20
> [PALEN]http://www.cs.colorado.edu/~palen/dissertation/LPdissertation.pdf
>=20
> [SKiCal] SkiCal - an extension of iCalendar
> http://www.ietf.org/internet-drafts/draft-many-ical-ski-05.txt
>=20

I will add a to do item regarding researching SkiCal to the to do list.

> kind regards,
>=20
> Peter Od=E9us
<snip>

Thanks Peter

Sincerely
Jeff Prickett


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>