Designing a Schedule Synchronizer

pinque has asked for the wisdom of the Perl Monks concerning the following question:

I have this program that I have to do. I need help as to what I should use in the way of code. I don't want you guys to do it for me just give me clues as to what I should do.I am very lost on this one. I do have the first page coming up but the rest of it is a mystery to me.

Schedule Syncronizer.

Start by having a way to login to the system. The user must be able to "subscribe" to the synchronizing system.

Only users registered will have access to other users’ schedules. They will have to register and select which current users are allowed to view their schedule.

When adding an appointment for yourself, select the slot, the duration and the topic, then add.

When looking for a slot for a suggested meeting, select the slot, duration, invited (from the registered user set). This slot will be "greyed out" in your own schedule until it is confirmed.

Confirmation process: Once you select the time slot(s) and invited users, the system will compare schedules and generate "hit" or "miss" results. If all users can meet, then it will grey out the slot in the other user’s schedule and ask him/her for confirmation (e-mail and in the schedule itself).

The "affected" user will accept or deny the request (using the system, not e-mail). When the system receives confirmation for all parties, the slot is blocked on all schedules.

Try with two users and expand when this works. Minimum functionality is for two users

Your availability files (for schedule) only need to consider a week.

jdporter added formatting markup

2005-11-26 Retitled by planetscape, as per Monastery guidelines
Original title: 'Totally Lost'

Comment on Designing a Schedule Synchronizer

Replies are listed 'Best First'.
Re: Designing a Schedule Synchronizer by Albannach (Monsignor) on Nov 25, 2005 at 22:03 UTC
Forget code for now, you need a design, and for that you need data structures that support the desired functions. Think about these questions, get some paper and start drawing: How do you store each user's calendar? What data items are needed? What actions must be taken on a calendar to add or remove an appointment? How will you whether appointments on different users' calendars represent the same meeting or not? Once you figure out that, the rest is just code to implement data changes (add to, delete from, check calendars), or carry out actions when data has been changed (like sending e-mails). -- I'd like to be able to assign to an luser	[reply]
Re: Designing a Schedule Synchronizer by talexb (Chancellor) on Nov 25, 2005 at 22:01 UTC
This is not a Perl question (yet) .. it's a programming question. So I'd start with the guts .. figure out a database structure that support the functionality you need (that's also known as the model). Then write functions that will talk to the database doing stuff like adding appointments (maybe checking for conflicts first? -- that's known as the controller). Finally, wrap the whole mess in a user interface (that's known as the view). Then you've completed a model-view-controller or MVC application. And please come back when you have a Perl question for us! Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re: Designing a Schedule Synchronizer by idsfa (Vicar) on Nov 25, 2005 at 21:02 UTC
Shouldn't you have started on your term assignment before Thanksgiving weekend??? I recommend you withdraw from the class and start earlier next time ... Failing that, start here, here and here. The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon	[reply]