> On Dec 13, 2015, at 8:06 AM, Sam Ruby <[email protected]> wrote: > > Quickstart: > > git clone https://github.com/apache/whimsy.git --branch secmail > cd whimsy/www/secmail
ok. [CraigRussell:~/apache/git/whimsy] clr% cd www/secmail/ [CraigRussell:whimsy/www/secmail] clr% ls Gemfile Rakefile config.ru parsemail.rb server.rb README config.rb mailbox.rb public views [CraigRussell:whimsy/www/secmail] clr% rake fetch1 rake aborted! Command failed with status (127): [bundle update...] /Users/clr/apache/git/whimsy/www/secmail/Rakefile:11:in `block in <top (required)>' Tasks: TOP => fetch1 => bundle => Gemfile.lock (See full trace by running task with --trace) [CraigRussell:whimsy/www/secmail] clr% rake server rake aborted! Command failed with status (127): [bundle update...] /Users/clr/apache/git/whimsy/www/secmail/Rakefile:11:in `block in <top (required)>' Tasks: TOP => server => bundle => Gemfile.lock (See full trace by running task with —trace) Now what? Craig > rake fetch1 > rake server > [navigate browser to http://localhost:9292/] > > Background: minotaur is going away, running scripts on the mail server is > discouraged, and the ability to debug locally the processing of mail is > highly desirable. Therefore, the current thinking is that whimsy will rsync > entire mailboxes from wherever they might be (this location may change over > time) and then process them locally. > > The above branch an exploration of what that approach might look like. It is > able to successfully parse over eight years of email (not a small feat given > that the current deployed secmail.py blows up occasionally when presented > with malformed email messages (typically spam). > > It then presents an index of email messages that have attachments, which you > can navigate into to see attachments. The only operations currently > implemented are: > > 1) delete and undelete entire emails. Do this by navigating (up, down, and > click) to the email in question and press delete (or backspace). Undelete > using either the button provided, or by using control-z (mac users can also > use command-z). > > 2) showing a context menu on an attachment. Navigate into an email and right > click (or control-click for Mac users) to see a list of operations. > > Notes: > > 1) fetch times are wildly inconsistent. Ten seconds on a high speed > connection should be enough for one month, but one to fifteen minutes is not > uncommon. I have, however, downloaded the entire corpus of secretary emails > since 2007 in less than hour. > > 2) The server is set up to restart if anything changes in the secmail > directory. The first time you start the server it will set up some files, > and that will cause it to restart, possibly after displaying some tracebacks. > Ultimately, this restarting on changes makes development easier. > > 3) functionally this code is structured much like the board agenda tool, and > should be a lot more maintainable than the current secretary workbench. In > particular, the code is much more modular, and adding a new function should > be able to be done without affecting existing function. > > 4) being able to test against the entire set of emails received is a big step > forward; but given that this code is structured like the board agenda tool, I > should be able to add proper tests. > > 5) I haven't focused on the UI yet - it needs a lot of work. I would like to > make this feel less like a web page and more like a desktop app that happens > to run in a browser. For example, I would like to explore having the current > 'staple' function be done via dragging and dropping of images and PDFs on top > of one another. > > - Sam Ruby Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
