The image above illustrates the overview of the components and processes within the scheduler system. The major components of the system are the directory, the agents, agent warehouse, and client application. The directory contains information regarding the users such as names, email addresses, and calendar locations. Agents carry the main tasks, specifically those related to generation of meeting schedules. In order for these agents to persist, a warehouse is needed which will ensure that the agents will remain running regardless of the log status of their users, and may also help in managing agent resources. Users run the client application in order to interface with their personal clients or the scheduler system in general.

The Directory

As said above, the directory will contain basic information about the users. One very important information that the directory will contain is the location of the calendars of the users.

Calendars are maintained independent of our system and so scheduler uses data that are not “locally” present. In addition, the provider of the data will have other ways to update them outside of our system giving them full control over their data. Furthermore, these data may also be used by other applications unrelated to the system.

The Agents

Agents will carry out most–if not all–of the tasks or functions that is expected from the application, which are mostly involved in coming up with meeting schedules–basically the intersection of free times (iCalendar) of people involved. These agents will “negotiate” among themselves when users ask them to make meeting schedules. They will act mostly on their own but will have to do so according to user preferences. For example, if users would not want to meet anyone within a given period of time even if that particular user has not specified his actual free or busy times, then the user’s personal agent will have to reject any attempt to schedule a meeting with him or her.

Scheduler agents may also do some calendar management tasks such as putting the meeting schedule generated by themselves or by others on their users’ calendars or deleting these entries when users do not want them. In the implementation of the system, the client application may include a calendar management module where users can manage their calendars directly. However, the agents may not help much on this.

Agent Warehouse

Agents are processes running on the system’s server. These agents must continue to exist even after their users have logged out of the system for the purpose of becoming open to other agents for scheduling. For this task, a warehouse may be used. The main problem here is that since agents will be implemented as processes, there must be a way to manage the resources they will use especially when the number of agents is relatively high.

We made the first draft of the architecture for the scheduler a week ago but I’m still to digitize the diagram completely. We also want to confirm the design as soon as possible (probably on Monday or on Wednesday). The diagram below shows the external system where the users publish their schedules/calendars.

The system consists of the user, a calendaring application, local storage, and CalDAV server. Calendaring applications such as Sunbird and iCal are available for the users. However, when users use these applications, data regarding their schedules are placed locally on their storage (hard disk drives, etc.) by default. In order to make their schedules available to the public, they can either export it to a file and distribute it; or publish the export to a remote calendar server. In which case their schedules are transferred in iCalendar (RFC 2445) format. Mozilla Sunbird, which is the application we’re using, allows publishing on either a Web-based Distributed Authoring and Versioning (WebDAV) or File Transfer Protocol (FTP server). However, on an FTP server, Sunbird exports on Sunbird format. WebDAV is an extension to the Hypertext Transfer Protocol (HTTP) for remote management of files and CalDAV is an extension of WebDAV for managing calendaring files. CalDAV messages are basically HTTP messages that comes with an iCalendar format file after the header. Obviously, export to CalDAV/WebDAV server is the best choice for us.

Now, data on the calendar servers are what the scheduler is going to use. The next thing we’ll have to look at from here is the process of interfacing between personal agents and the servers. Below are some points to consider:

• iCalendar data processing for agents
• Security (will agents be able to access data on the server)
• Agent-server communication

Supposedly, on a Semantic Web setting, the calendar publishing service will have an agent with which our agents could communicate. But since we are on the initiative, we’ll have to consider another way of communicating with the servers on the current setting. Another future application that can be thought of from here is local holidays. Users should be using a local calendar service which will automatically contain information on local holidays. They can then choose to associate the information with their schedules. This association can either be done through the calendar service agent or our agents.

The diagram and details of the rest of our design will follow as soon as possible (probably on Tuesday).