Correction: always use *null* in the "message_attributes" column definition, in order to get full backward and forward compatibility.
Vincenzo > -----Original Message----- > From: Vincenzo Gianferrari Pini > [mailto:[EMAIL PROTECTED] > Sent: gioved� 14 agosto 2003 18.14 > To: James Developers List; [EMAIL PROTECTED] > Subject: RE: Fetchmail patch(es) > > > Steve, > > > > One thing that you might want to do is change the use of X-Headers to > > > attributes, since this will go into v2.2+. Attributes are > > > available for > > > both v2.2 and HEAD. I would only use X-Headers for something > > > you want the > > > MUA to see. > > > > Yes, I thought about this. My concern with such an approach is that as > > attributes require a database, file based systems will not then > be able to > > use fetchmail. While fetchmail is not an essential James > > component, deciding > > that any James component (in the Phoenix sense) need not support > > file based > > systems is more of a strategic decision than I alone should be taking. > > > > Hmmm. Maybe a <UseAttributes>true</UseAttributes> flag would do it. > > > > No, mail attributes are available also for file based > repositories in James: moreover, they are immediately fully > available from the moment you start using v2.2.0a9, if using file > based repositories, while instead you need to do some work to > activate it if using DB repositories (better, to achieve persistance). > > As written in this list under "Mail Attributes support added", > amended by "Mail attributes: backward and forward compatibility": > > ... > Such support is immediately available just by restarting the > server if James uses file based repositories for inbox and > spools, *even if there are messages in the queues*. > > For db based repositories instead the following steps must be > done, depending on the following three situations: > > 1) No "inbox" and no "spool" tables exist (no db repositories > yet): just look for the string "attributes support" in > james/apps/james/conf/sqlResources.xml, uncomment/comment the sql > statements as described there and restart the server. > > 2) Both "inbox" and "spool" tables exist, but there are NO "old" > messages to keep residing in the repositories: do the > comment/uncomment as said in (1) above, and either drop the > tables form the db and restart the server (if you haven't done > any customisation) or add the "message_attributes" column to both > tables with *not null* and restart the server. > > 3) Both "inbox" and "spool" tables exist, but there ARE "old" > messages to keep residing in the repositories: do the > comment/uncomment as said in (1) above, and add the > "message_attributes" column to both tables with *null* and > restart the server. > ... > > So it would be safe to follow Noel's suggestion for fetchmail. > > Vincenzo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
