Along these lines, if we have an "rfc822" object, what operations
would we want to perform on it ? What other objects would be useful ?
A "folder" object ? A "part" object for handling "multipart" MIME
* save/fetch a message object to/from "folder" for messages in ZODB
* dissemble a multipart MIME message into "part" objects in memory
* write a "part" to/from a file
* write a "Multipart" object to a "multifile"
* "send a message" into the ZODB "folder" from the outside
* "send a message" from the ZODB "folder" to the outside
* search for message by attributes
These operations would be methods on the "rfc822" object, "part" object
and ZODB "folder" object, invoked appropriately ( locally or via
remote calls ).
Chris McDonough wrote:
> I'm interested in this, although I have a lot on my plate right now and
> can't help in development.
> I see objects in Zope being able to handle a call to one of their
> methods that passes off a chunk of email text and stuffs it in an
> attribute for later display or catalog.
> I think you should probably start by designing the interface to these
> kinds of objects and worry about exactly how you're going to call the
> methods that make up the interface later...
> > -----Original Message-----
> > From: Simon Coles [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, May 31, 2000 11:54 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Zope] Proposal for mail-in to Zope
> > Hi,
> > We (NIP - in the form of Chris Withers, Stephen Harrison, and Simon
> > Coles) have put some thought into the question of how to get emails
> > into Zope, and have come up with a design which we thought we'd pass
> > by the list before we start doing something.
> > The problem we are trying to solve is basically being to email
> > "[EMAIL PROTECTED]" and that email ends up in the Zope ZODB
> > processed in whatever way is appropriate.
> > We aren't worried about sending email, that's done well at the
> > moment. We also wanted to keep things as simple and quick as possible
> > :-) This means trying to avoid getting involved with mail systems as
> > much as we can.
> > Most MTAs can be setup to pass an email to the stdin of a program.
> > Sendmail will do this, and Exim (http://www.exim.org/) will also pay
> > attention to what that program returns and queue the message for
> > re-try later if it fails. So using Exim, we don't have to get into
> > any messy stuff about queuing mails if the Zope server is down.
> > Some alternatives we considered and didn't go for:
> > - write something in Zope to listen for SMTP
> > connections, effectively
> > large portions of an MTA. This would be cool but painful.
> > - pull mail from a POP or IMAP server. This had the
> > downside that it
> > introduced polling into the system (slow) and also
> > required something
> > to happen on a schedule, which doesn't happen in Zope yet.
> > So:
> > - Within Exim, use the "pipe" transport to get email
> > for a particular
> > host sent to a program on the standard input. If the
> > program called
> > returns certain codes then Exim will queue the
> > message and try again.
> > - This program takes the email message and puts it into
> > Zope, probably
> > by calling a DTML Method or something. This would probably be
> > configured by objects in the Zope ZODB which say
> > effectively "When
> > you get email for this address, then call this Method".
> > - The DTML Method is responsible for doing the right
> > things to get
> > the email message into the ZODB in whatever form is
> > appropriate.
> > We haven't yet figured out how to make sure the above mail handling
> > program can find all the relevant configuration documents. Is there
> > some way of efficiently finding all instances of a particular ZClass?
> > (Chris W. still isn't sure that's how the configuration will work but
> > that's the plan for the moment, so any thoughts would be appreciated)
> > What we'll do is a first version that hard codes everything in the
> > above script and prove the principle of the thing, and then move onto
> > the configuration.
> > Does this sound like what people need? Any thoughts,
> > comments, warnings?
> > I don't know yet what kind of schedule we'll be able to do this on
> > but drop me a mail and when there's something to play with we'll let
> > you know.
> > Simon
> > --
> > --------- My opinions are my own, NIP's opinions are theirs ----------
> > Simon J. Coles Email: [EMAIL PROTECTED]
> > New Information Paradigms Work Phone: +44 1344 753703
> > http://www.nipltd.com/ Work Fax: +44 1344 753742
> > =============== Life is too precious to take seriously ===============
> > _______________________________________________
> > Zope maillist - [EMAIL PROTECTED]
> > http://lists.zope.org/mailman/listinfo/zope
> > ** No cross posts or HTML encoding! **
> > (Related lists -
> > http://lists.zope.org/mailman/listinfo/zope-announce
> > http://lists.zope.org/mailman/listinfo/zope-dev )
> Zope maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-dev )
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -