This document will describe the current map of where Scribe is going over the next little while.

The following table describes the client-server relationship of protocols and software. This shows how I intend to extend the software to allow for more traditional groupware functionality.

Client	Server
Mail Software: Scribe	Mail Servers Software: Memecode Server (Local only POP and SMTP) (Other 3rd party mail servers) Protocols: Pop3. Smtp. Imap.
Contacts Software: Scribe Format: vCard	Shared Contacts Software: Scribe LDAP Server. OpenLdap. Netscape Server. M$ Exchange. Protocol: Ldap.
Calendar Software: Scribe Format: vCalendar	Shared Calendaring Software: Memecode Server Protocol: SCP over HTTP Reference: IETF rfc's
Todo List Software: Scribe	Shared Todo Software: Memecode Server

The internal structure of Scribe itself as an application needs to be extended and opened up to allow more functionality. This may effect size and speed to some degree but I feel it's worth the effort.

Scribes architecture is broken into 3 layers, where data is copied between layers at run time through fairly generic interfaces.

• The bottom layer is storage which is responsible for the persistant data store, which basically at the moment means the folder file.
• The next layer up is the object layer that contains a manipulatable version of the objects. This is used in the sending/receiving, copy/paste, selection/folder UI etc.
• The top layer allows editing of individual objects in detail, and this is based around SDI windows with LGI controls. This is what the user sees and touches.

The flexibility of these layers to talk to each is limiting the functionality of Scribe at the moment. The following table describes the state of affairs and the direction I want to go with the layer architecture.

User Interface	Existing implementation: MailUi Plugin: Text pipe filters can process blocks of text in the editor. E.g. a spell checker or encrypt/decrypt plugin. Pgp Plugin Plugin: Mime type viewers. IE HTML Plugin The MailUi could be enhanced by having a more complex editor, capable of including all sorts of text, images and formatting. This isn't as tough to do as I originally thought but it's a major component. It would allow reasonable support for HTML mail, both editing and viewing in a cross platform compatible way. ContactUi Custom fields. Multiple email addresses per Contact. CalendarUi Week, Month and Year view. Day view. Todo list. FilterUi Scripting Plugin for advanced filtering. Advanced condition tree option as well as OR'd and AND'd list of conditions. As long as the Object layer API is much the same then this won't required much change.
Object	Mail passes vertically between the following stages: Mail Source Transfer email from the specified server into Scribe: Simple mail source: Pop3 Imap (fetch) Mapi (fetch) Plugin API for simple mail source. Plugin: Online mail source, requires online storage: Imap (Remote management) Mapi (Remote management) MBOX Mail Store Incomming Mail Filter Plugin: Can manipulate mail object before being stored. InScribe Filters. Local Mail Flattens MIME data into: 8bit text. Html List of attachments. This will need to change to a more flexible object. The main problem is that filters that processing email being sent & received will want to access detail in the MIME parts that isn't stored in the internal Mail object. However if the mail object followed the MIME format more closely then the filters could edit MIME headers of sub-parts etc. Think MIME-PGP auto-encrypting/decrypting. Contact List of properties. Each with a named value, of int, float, text or binary. Calendar List of properties. Each with a named value, of int, float, text or binary. Filter List of condition objects. List of action objects. Rewrite: It would make sense to make all the objects into generic property lists and remove any direct C++ member variables. This would make for more generic code and intergration of plugins. I'm just not happy with adding more time to either data lookup time or property insertion/deletion. Outgoing Mail Filter Plugin: Can manipulate mail object before being sent. Mail Sink Smtp
Storage	Local storage in a flat file of typed - heirarchical objects. Objects are binary data or explicit length, passing in by the object layer. Online only storage: Mounting online storage systems, ala IMAP and so on and displaying them in amongst the folders and items. Offline: Flat file object store. Flat file indexing database. Online: Plugin: Transport layer plugins for SOCKS, SSL etc. These will sit between the app and the OS to provide connectivity. TCP/IP Direct connection.