> 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
+1 so far. > > 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. If its serializable it should be TEXT, MEDIUMTEXT or LONGTEXT, and the same really applies to message body too. IMHO. > 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. +1 error_message, remote_host, remote_address > > --- Noel > > > -- > To unsubscribe, e-mail: > <mailto:[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]>
