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

[Marco O. <Mar...@we...>]

Hello!

Thank you for your comments. I pool my answers to your
comments in this mail.

Stewart Greenhills objection that mail bodies can get very large
is right and I see some danger in this too, but as Tim Teulings
stated in a later mail the module I proposed doesn't do much
alone. I would put most (or even all) of the things Stewart wrote
about into different modules. I think it might be better to use
something else than String for the body just because it can
be large. But I don't know what type I can use. I don't want
to program one on my own for that module. For different purposes
I think persistent text-objects you mentioned are a good idea.
I consider providing a SetText-method which reads from a Rider
instead of copying a string. Copy? May be this is not needed
for String-Parameters (it could be done be the client module
if necessary.)

Michael van Acken wrote:
> For the "simple" case (moderately sized messages, not MIME formatted,
> etc.) any string represention will do. =A0This includes a string for
> every line, the whole mail in a single string, or storing the mail in
> an instance of IO:Memory (part of libxml, a in-memory channel
> implementation).
I will take a look at IO:Memory.

Tim Teulings wrote:
> Hallo!
>
>
> It seems to me, that this API only features the most basic
> methods for accesssing parts of a message. For more
> full features the API has to have more features or (which
> may make more sense) there have to be additional APIs on top
> of that.
Yes. That was my intention.
>
> For example:
>
> What about encodings. AFAIK some of the headers and the body
> can be encoded in an special fontset. What about MIME, attachements
> etc...
Encodings and MIME have to be handled by modules which display
actual content of a mail or convert it into data which has to have a
specific encoding.
>
> As said, this does not mean that you must expand the API, itmay be
> enought to have an cncept in mind, for expanding the API for this
> highler level features.


Greeting,
 Marco