Scheduler Architecture
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).
