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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
