EOAST - Evolution of a software thingy - Part 3

This is the the third instalment of my experiences and ideas around the development of a piece of software to initially satisfy my disappointment around Outlook and also to allow me to play with some new technologies and making them all work together. Part 1 is here and Part 2 is here.

This latest instalment will focus a little more into the design detail. The "InformationAggregator" (as I have coined this project) is intended to be fairly generic as to the kind of information it collects but is still somewhat specific in that all types of information ever thought of is a bit too grandiose. For the most part, email, RSS, meetings, tasks, journal entries, notes and those types of things are the initial concern.

Central to this is the "GenericInformationItem" that is used to house individual elements of information. Below is a class diagram of the object:

I'll go through the non obvious items to explain how I see them working. Note that this is a work in progress, so things are bound to change as I go further down the path.

BodyBinaryData and BodyTextData: These properties are obviously the body component of the information item. BodyBinaryData might typically be images or pretty much anything you like in binary form. It does not lend itself to searching its contents though, and this is somewhat mitigated by searching on things like Title, Author & Summary fields, but this still may not be quite sufficient. BodyTextData is any textual portion of the information item body and is easily searched. Email body, RSS item content, note content are obvious candidates here.

InitialDateTime and EndDateTime: My thinking here was to mainly cater for meetings/appointments. InitialDateTime can also be used for the start or creation date/time (depending on what information item is being modelled). EndDateTime may not always be used but could also be adopted for expiry dates (again, dependent on the information item being modelled and contextually known about by the information provider and display modules).

SourceProvider: This is the name of the InformationProvider module that provided the InformationItem. Queries and mapping against InformationDisplay modules work against this property. Only registered InformationProviders will have their data accepted and stored in the repository.

LastNotification, NextNotification and NotificationRequired: These fields control whether this module and associated collected information items support notification and any display providers should take this into account and display a notification when an item requires notification. The way a notification is display (if at all) is at the discretion of the InformationDisplay module.

InformationSource: This property indicates the original source of the information. This might be a URL, file location, email account or anything.

Status: This property indicates if the InformationItem is in fact an error item. These items typically aren't stored in the repository as normal information but are used to communicate errors to various modules and the engine itself, and are reported in event logs, traces etc.

So that's a small insight into the detailed design of this software thingy aka InformationAggregator

The next instalments will begin the focus on the interface implementations and how I see data going back and forth to the engine. Hopefully its not too boring, and as I mentioned, t his is a work in progress. I welcome any critique, suggestions and feedback.