Re: [ooc-compiler] Proposal for an Email-Module; RFC

[Stewart G. <sgr...@ip...>]

Hi Marco, 

> I would like to have your comments on my idea
> implementing the module described below.
> I want to use libadt. Does anyone think that
> the String-Module is not sufficient for holding
> single lines of the mailheader and the body?
> I would like to know if something is missing
> or not useful.

Mailheaders should be no problem. However, some mail bodies can be very
large, especially with attachments. I occasionally get messages that may be
several megabytes in size. It might be worth considering something like the
Blackbox TextModel (ie. a persistent mutable text that is backed by a file)
instead of String. I think that this is derived from the Oberon System
concept of Text. There isn't really an analog in the OOC framework. 

If you don't need to be able to edit the mail in-place, an alternative
might be to implement a wrapper Channel that simply allows access to a
portion of another Channel bounded by a start and end position. This way,
you could maintain your mail messages in a file and then Mail.GetBody could
return a TextRider.Reader that accesses just that portion of the file that
corresponds to your message. Alternatively, you could copy the text for a
message into a temporary file and return a TextRider.Reader on this data.

With some extra thought, it might be possible to generalise the concepts
here to produce a generic Container/Object framework. Eg. a container is
simply a file containing a collection of objects with associated
attributes. One could use the attributes as criteria to search the
container, but the objects theselves might be any data objects. Text can be
accessed without loading it into memory, so it would still be useful to
have a separate facility for this, especially since mail messages can be
very large texts. Thus you might have:

PROCEDURE (m : Mail) SetText * (rd : TextRider.Reader);
PROCEDURE (m : Mail) SetTextString * (text : ARRAY OF CHAR);
PROCEDURE (m : Mail) SetObject * (obj : ADT:Object);

PROCEDURE (m : Mail) GetText * () : TextRider.Reader;
(* maybe *) PROCEDURE (m : Mail) GetTextString * () : String.String;
PROCEDURE (m : Mail) GetObject * (VAR obj: ADT:Object);

PROCEDURE (m : Mail) IsObject * () : BOOLEAN;
PROCEDURE (m : Mail) IsText * () : BOOLEAN;

Note that the underlying mechanism behind GetText and GetObject are very
similar. You would simply need to maintain a flag indicating what sort of
data is held within the message. To access the message, you would make a
wrapper channel or copy for the relevant range of the file, and then use
TextRider.ConnectReader or ADT:Object.InitReader to create the Reader. For
text, just return the Reader; for objects, call Reader.ReadObject to
internalise the object. It would probably also be necessary to incorporate
some sort of locking, so that you can't delete or reclaim a message that is
currently being accessed.

For SetObject/SetText, you would need to find enough free space in the file
to hold the data. For SetText, you know how much space is required (via
Reader.Available). For SetObject, you would need to externalise the object
to a temporary Channel first in order to determine the size of the data.
Apart from that, its basically a heap-management problem: keeping track of
used/unused regions in a file. If you're interested I have some Component
Pascal code to do this, but it depends on Win32 memory mapping and is not
portable. Of course, if you can load the whole container into memory its
_much_ easier to implement. Another way to simplify the problem is to
always write to the end of the archive, and then periodically compact the
archive by making a new copy that omits any messages that have been
deleted.

> Traversal and modifications of a collection of
> mailing is done by Iterator-Methods. I would
> like to allow traversal independant of the
> actual sequence of storage. One Iterator could
> use Subject: while another uses Date: as
> sort criteria.

Make sure you handle concurrent iterations. Eg. one iterator deletes a
record that another is positioned over. Its probably simplest to forbid it.
 
> I took a short look on the sources in the Oberon
> System. Mail is there tightly coupled with the
> user interface and distribution protocols. I
> want to keep these aspects apart. The below
> module just describes the interface to some
> data containers. Sending and receiving mail
> just as storage should to be placed outside
> this module. Please tell me if you think this
> way is wrong and why.

I think it is wise to separate the two. 1) You can generalise the
functionality. 2) You can independently maintain the implementations and
interfaces without exposing any unnecessary dependencies.  

Cheers,
  Stewart

> 
> Greetings,
>  Marco
> 
> MODULE ElectronicMail;
> 
> TYPE
>   Mail * = POINTER TO MailDesc;
>   MailDesc * = RECORD
> 
>   END;
>   MailContainer = POINTER TO MailContainerDesc;
>   MailContainerDesc = RECORD
> 
>   END;
>   Iterator = POINTER TO IteratorDesc;
>   IteratorDesc = RECORD
> 
>   END;
> 
> CONST
>   (* Sortcriteria *)
>   headerElement = 0;
>   body = 1;
>   date = 2;
>   none = 3;
> 
>   PROCEDURE (m : Mail) SetHeaderEntry * (desc, content : ARRAY OF CHAR);
>   PROCEDURE (m : Mail) AddHeaderEntry * (desc, content : ARRAY OF CHAR);
>   PROCEDURE (m : Mail) GetHeaderEntry * (desc : ARRAY OF CHAR):String.String;
>   PROCEDURE (m : Mail) GetHeaderEntry * (index : LONGINT;
>     VAR desc, content : String.String);
>   PROCEDURE (m : Mail) SetBody * (body : ARRAY OF CHAR);
>   PROCEDURE (m : Mail) GetBody * ():String.String;
> 
>   PROCEDURE (m : MailContainer) GetIterator * (sortCriteria : INTEGER;
>     header : ARRAY OF CHAR);
> 
>   PROCEDURE (m : Iterator) Init *;
>   PROCEDURE (m : Iterator) Next * ();
>   PROCEDURE (m : Iterator) Forward * (n : INTEGER);
>   PROCEDURE (m : Iterator) First *;
>   PROCEDURE (m : Iterator) Last *;
>   PROCEDURE (m : Iterator) Get * ():Mail;
>   PROCEDURE (m : Iterator) Insert * (m : Mail);
>   PROCEDURE (m : Iterator) Lock *;
>   PROCEDURE (m : Iterator) IsValid * ():BOOLEAN;
> 
> END ElectronicMail.
> 
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> http://lists.sourceforge.net/lists/listinfo/ooc-compiler