Add the retry count as a distinct field. The error message field is currently used for this.
Steve > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > 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/[email protected]/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-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
