james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Short <Steve.Sh...@PostX.com>
Subject RE: [VOTE] Changes to database table structure and class Mail
Date Thu, 01 Aug 2002 22:02:09 GMT
Add the retry count as a distinct field.  The error message field is
currently used for this.


> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com] 
> Sent: Thursday, August 01, 2002 2:33 PM
> To: James Developers List
> Subject: [VOTE] Changes to database table structure and class Mail
> Serge,
> re: 
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02862.html
> I can add a serializable Map (probably a HashMap) to Mail, 
> and I can write a utility to convert the database format to 
> account for the table change(s).
> Do I need a vote on this?  I'd like not to do all the work, 
> and have the concept voted down.
> Specifically, we are proposing that org.apache.mailet.Mail 
> now include support for a Map allowing attributes to be 
> dynamically associated with mail instances.  These attributes 
> are different from X- headers, and are intended to be provide 
> internal (and unforgable) communication of metadata within 
> the James server.
> The map can be exposed via explicit methods, a la the Servlet API:
>    public void setAttribute(String, Object);
>    public Object getAttribute(String);
>    public Object removeAttribute(String);
>    public Enumeration getAttributeNames();
> by exposing the Map:
>    public Map getAttributes();
> or by being a Map:
>    public interface Mail extends Serializable, Cloneable, Map
> I know what my suggestion would be, but I'm opening the topic 
> for discussion.  Regardless of how we expose it, the new Map 
> would be stored as a BLOB in the table, thus stored/retrieved 
> as a unit.
> Next, Serge is proposing that the error message be moved from 
> a separate field to the attribute map.  My proposal would be 
> that any such properties be added to the Map, and have their 
> set/get methods deprecated.  What other properties, besides 
> error, should be moved?  Perhaps the remote host and remote 
> address properties.  I don't see any others that appear to be 
> good candidates.  Message state is separately queried, and 
> I'd like to keep that lightweight query available.
> So ... we need to make a decision so that this can be implemented.
> 	--- Noel
> --
> To unsubscribe, e-mail:   
> <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:james-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message