Weblog for Costin Manolache

More on FutureTask

2009-06-04T11:33:00.001-07:00

Adding to my previous FutureTask post: Future is a very nice interface, but the main problems with FutureTask are the lack of a callback and the clumsy constructor that requires a Callable. I guess their main use case was someone creating a FutureTask that performs a slow operation - as in my example, it is relatively easy to wrap the method in a Callable and then execute the FutureTask in a thread pool. It is possible to add a callback by overriding FutureTask.done(), which is called after FutureTask.set(). There are few tricks to better use FutureTask. Let's say you have an operation that happens in background already, and you're notified with a callback. You want to wrap it in a Future to make it easier to use:

  interface Callback {
    void done(Object1);
  }

  void doSomethingAsync(Callback callWhenDone) {
  }

  class MyFuture extends FutureTask {
    public MyFuture() { 
      // FutureTask _requires_ a callable - even if it's not using it. Let's give him a dummy one.
     super(new Callable() { public Object1 call() { return null; }});
    }
    // set() is protected - need a visible method to let future know the result 
    public void gotTheResult(Object1 result) {
      this.set(result);
    } 
  }	

  Future<div class="youtube-video"><object1> getSomethingFuture() {
    final MyFuture res = new MyFuture();
    // We _don't_ submit it to an executor - so run() will not be called
    doSomethingAsync(new Calback() {void done(Object1 result) {
      // do what innerRun() does - i.e. call innerSet with the result. 
      // innerSet() will set state to RAN , even if the callable was never called.
      res.gotTheResult(result);});
    return res;
  }

My synergy settings

2008-11-10T15:51:00.001-08:00

I have multiple laptops and computers, and sometimes use them at the same time - it is convenient to use a single keyboard
and mouse. The problem is that the config is not fixed - and synergy is quite hard to reconfigure dynamically.

I start a synergys server on each computer whose keyboard I may use, and use a couple of scripts to create tunnels and
restart the clients.

The trick is to not use specific hostnames - but dummy ones, and explicitly set the "-c clientname" param. Then all real
config is done using ssh tunnels - with the extra benefit of

Server:
synergys -n localhost -a 127.0.0.1:24800

# optional: ssh to shared server ( if the keyboard host is behind another firewall ):
ssh -f -N -R 24800:127.0.0.1:24800 public_computer_with_sshd

Server config: ~/.synergy.conf

section: screens<br />      localhost:<br />      up:<br />      down:<br />      left:<br />      right:<br />end<br /><br />section: links<br />      localhost:<br />        down = down<br />        up = up<br />        left = left<br />        right = right<br />     up:<br />        down = localhost<br />     down:<br />       up = localhost<br />     left:<br />       right = localhost<br />     right:<br />       left = localhost<br />end<br /><br /><br />

On client:

   ssh -N 24800:127.0.0.1:24800 server &
   echo $! > ~/.synergyssh.pid

   killall -9 synergyc
   synergyc -n down localhost

I have few client scripts, pointing to different keyboard servers and layouts.

Intercepting SIGTERM

2008-08-14T13:32:00.000-07:00

The 'proper' way to terminate a java process on unix is by sending SIGTERM, waiting a bit, and then sending SIGKILL. This gives java a chance to clean - using Runtime.getRuntime().getShutdownHook(). If you want to intercept this and do some early cleanup, before letting the others do theirs you need to use sun.misc.Signal - which can also be used to intercept other signals. Things to do in a shutdownHook ? Flush the logs, finish important background processes and much more. Code to intercept the signal:

oldSigTERM = Signal.handle(new Signal("TERM"),
                new SignalHandler() {
    public void handle(Signal signal) {
      System.err.println("Quit using SIGTERM hook");
      notificationHandler.prepareToQuit();
      if (oldSigTERM != null) {
        oldSigTERM.handle(signal);
      }
    }
  });

Common-sense on unit testing

2008-08-08T17:42:00.001-07:00

The Cafes » Harold’s Corollary to Knuth’s Law

Using FutureTask

2008-03-20T10:46:00.001-07:00

This is what I typically use to convert a sync method to a background Future. The benefit is that it avoids a lot of custom code (creating threads, locks, etc ) and seems simple enough, and it's relatively easy to cut&paste.

Original:

 
  Result1 slowMethod1(Param1 p1, Param2 p2) throws Exception1 {
  }
  Result2 slowMethod2() throws Exception2 {
  }

  void caller() throws Exception1, Exception2 {
    // slowMethod1 and slowMethod2 are independent of each other
    Result1 r1 = slowMethod1(p1, p2); // first expensive operation
    Result2 r2 = slowMethod2(); // other slow method, not using the result or side-effects of the first
  }

New code:

 
  Executor bgTasks = Executors.newCachedThreadPool(); 

  Future slowMethod1Future(final Param1 p1, Param2 p2) {
    FutureTask  fr = new FutureTask(new Callable() { 
      public Result1 call() {
        return slowMethod1(p1, p2);
      }
   });
    bgTasks.execute(fr);
    return fr;
  }

  void caller() {
     Future fr = slowMethod1Future(p1, p2);
     Result2 r2 = slowMethod2(); 
     try {
      Result1 r1 = fr.get();
    } catch(InterruptedException e) { 
       throw new RuntimeException(...);
    } catch (ExecutionException e) {
       Throwable t = e.getCause();
       if (t intanceof Exception1) { 
         throw (Exception1) t;
       } else {
         throw new RuntimeException(t);
      }
    } 
   }

JConsole in local mode and tomcat

2008-02-27T21:17:00.001-08:00

After some debugging found that Jconsole will connect locally to a new MBeanServer created via ManagementFactory.getPlatformMBeanServer(). Tomcat will look for an existing MBeanServer and create one if needed - but this will be different than what jconsole uses.

The fix is 2 lines - benefit is that you can start tomcat normally, without any special flag, then connect with jconsole and inspect/modify settings. It looks like they use some signal or other form of communication on Linux, which opens a TCP port.

I'm not sure why someone would ever want to use MBeanServerFactory.findMBeanServer() and createMBeanServer. Sure, in the rarely used sandbox mode, if you want to strongly isolate apps it may be needed - assuming you want each untrusted app to have access to its own server, and grant it create mbean server rights.

Time to send a patch - long time since I haven't done that...

OFX download for vanguard

2007-12-25T22:29:00.001-08:00

I've been using ofx.py to get my transactions from Vanguard, it stopped working sometimes this month. I have some code to parse and merge the sort-of-xml responses to an .xls file - which for me works much better than any alternative I tried. Moneydance is close, it provides an API that can be used to extract same data and it's a bit easier to setup, but it does some magic and seem to be less stable. Quicken, Money - never found a way to get my data back, and won't work on linux too well.

Made few changes to get it working again, first the setup is:


               "caps": [ "SIGNON", "INVSTMT" ],
               "fiorg": "vanguard.com", 
               "url": "https://vesnc.vanguard.com/us/OfxDirectConnectServlet"

The main change besides url is the code to get the transactions, urllib2 seems to default to HTTP/1.0, couldn't find a way to force it to 1.1 so I changed the code to use httplib directly:


            garbage, path = urllib2.splittype(self.config["url"])
            host, selector = urllib2.splithost(path)
            h = httplib.HTTPSConnection(host)
            h.request('POST', selector, query, 
                      { "Content-type": "application/x-ofx",
                        "Accept": "*/*, application/x-ofx"
                      })
            res = h.getresponse()
            response = res.read()
            res.close()

Old:


        request = urllib2.Request(self.config["url"],
                                                query,
                                               { "Content-type": "application/x-ofx",
                                                  "Accept": "*/*, application/x-ofx"
                                               })
        print "RES: ", res, " ", res.status, " ", res.reason
       f = urllib2.urlopen(request)
       response = f.read()
       f.close()

JAAS and tomcat

2007-09-29T17:10:00.001-07:00

The JAAS ( authentication/authorization ) API has been around for many years now - the idea is to use a standard API for all authentication, and plugins to use NT, LDAP, PAM, SSO and any other realm. JAAS seems modeled after PAM - the auth API for linux ( and unix in general). Tomcat supports JAAS auth and provides a sample LoginModule based on the simple clear-text xml file. Like most other apps using auth, tomcat also have direct modules to authenticate against DB, LDAP/JNDI, files - but it will never cover the same range of auth sources as PAM for example ( http://www.kernel.org/pub/linux/libs/pam/modules.html ). JAAS has few big problems - it is quite complex, it lacks modules and it lacks users. A benefit of using a tomcat-specific module is that it can be better optimized for the target environment. The only reason to use it would be to use a PAM auth source, there is now a JAAS-PAM implementation http://jaas-pam.sourceforge.net/ - seems very good, LGPL, uses JNI to interface with PAM. The default JAAS modules from Sun seem quite useless - they can authenticate the current user, not much more. The JDNI module is probably usable, but the tomcat JNDI source seems more customizable and simpler. Another option that wraps PAM is SysAuth (GPL2), it defines it's own simpler API, it could be wrapped in JAAS or in a tomcat module. Due to license and the fact that jaas-pam exists - probably not worth the effort. Another dead end is ShadowJAAS - it supports unix user/password authentication, by parsing passwd/shadow files in a SUID root file.

JMX names

2006-05-11T11:28:00.000-07:00

Sun's advice http://java.sun.com/products/JavaManagement/best-practices.html

Allways have type=
if singleton ( or one instance per domain ) - no other key
otherwise: add name=
for grouping, add group=
j2eeType/jsr77 - they kind of agree it's a messs - I think
they do actually define a 'containment scheme', using type=Server.Application.WebModule,.. and Server=, Application=, etc. Not quite JSR77 - but close enough., and it makes more sense.
of course - an easier solution would be to just use unix-like names name=//servername/appname/webname,

On mbeans, they advise:

use standard MBeans - and use the interface with newProxyInstance. Not sure I agree with this one, if you want this kind of programmatic access use RMI/corba/etc if out of process, and the object directly if you are in process - you still have coupling and dependency, but no need for the JMX layer, which is not designed as RPC and is more inefficient than direct calls.
advice against DynamicMBeans - instead extend StandardMBean. I strongly disagree with this one.
On model mbeans, the correctly mention that they are hard to use by themself. The fact that they can't have interfaces is false AFAIK, you can define the interfaces if you want and the proxy will be generated, you can construct a dynamic proxy for anything if you want to write the interface. There is a decoupling since the implementation doesn't have to implement the method, but this can happen in any case if one side changes attributes/methods. See the above point on why I think dynamic proxies for JMX are a convoluted and bad idea.
recommend using OpenMbeans - good idea, and avoiding RMI-specific features like downloading classes.

As usual for any 'best practice' document - don't believe all they say, ask first what 'practice' they had and how many applications they developed or considered before finding the 'best', and how they relate to your use case.

Cleaning a firefox profile

2006-05-08T10:07:00.000-07:00

http://robert.accettura.com/archives/2006/05/03/cleaning-a-firefox-profile/

JamVM -- A compact Java Virtual Machine

2005-11-22T10:38:00.000-08:00

JamVM - impressive VM, runs tomcat without problems, even eclipse works. All in less than 1/2 M. Speed is decent for simple use. And it supports ARM - so I can play with java and tomcat on my toys.

Dashboard/konfabulator for Linux and firefox

2005-10-07T13:48:00.001-07:00

Dashboard/konfabulator for Linux and firefox: "The 'killer feature' in Dashboard and konfabulator is (IMO) the ability to integrate a web-like interface with the OS. This opens the way for a lot of ideas in making Linux easier to use - for 'regular users' but also for advanced users who feel more comfortable using the browser than typing ( and remembering ) complex command lines. The implementation for firefox of a 'system/exec' feature similar with dashboard and konfabulator is not trivial, but not that complex. As I mentioned in a previous post, the async execution is the tricky part, but it has a reasonably straight solution. I'll try to find a server and post the sources - I'm sure there are better implementations using the event queue, but it works well enough for me. Now the remaining part is dealing with installing and running 'widgets' in firefox - and exactly emulating the interface. I'm not expecting Dashboard widgets to work unmodified, but with small changes.Â Konfabulator has an simpler interface, but it's not HTML-like, I'll only see if I can implement a similar API for simpler transition. This has been a very interesting mini-project for me - I found a lot about how firefox works, and I hope it'll serve it's purpose and I'll be able to reduce my use of CLI and have a nicer interface for the linux commands I use. Even if some already have"

A different implementation for commons-logging

2005-10-07T13:48:00.000-07:00

Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging.Â  It is also one of the not-so-good APIs or implementations. The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution. An alternative - that will work better in most cases - is to write a specific commons-logging implementation forÂ  eachÂ  backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars. The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic">A different implementation for commons-logging: "Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging.Â It is also one of the not-so-good APIs or implementations. The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution. An alternative - that will work better in most cases - is to write a specific commons-logging implementation forÂ eachÂ backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars. The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic"

RSS for comments and ids

2003-03-07T20:50:00.000-08:00

I got Sam's comment feed - and it imediately broke my agregator. The problem is quite simple - I use the link of the item as a key, and in the comment feed all
comments use the same key as the article. And the same title.

This changes the entire data model - for each link I'll have to store a list of MD5s, and treat it as a multi-value. The first time ( if no MD5 is found ) it'll be the "source" message, and all other occurances - including edits of the original - can be treated as "Re: " - to implement the threading in the mail reader.

Probably I'll just go for the simplest solution - and keep a .db keyed by MD5 (that should be unique enough ) - the whole idea is to avoid sending the same item multiple times.

Once again - the RSS proves to be almost completely useless.

Update: Sam changed the links. There are few problems. Some of his links are quite strange .../blog/('1247.html#c1047152121',), I suppose a small bug sneaked in.

Worse - I now lost the way to relate comments with postings. I'll have to parse the generated links and remove the ending to guess the original posting. Sam - please change back, I fixed my code to deal with the old problem and I think the workaround for the new problems is harder :-)

A better solution would be to just add a separate tag with the comment id. Of couse, that would be in the RSS-2003-03-08 "standard", and nobody else will use the same tag name. ( we should use the date of the "standard du jour")

Outlook mail aggregator

2003-03-07T15:07:00.000-08:00

It seems there are other people who preffer the mail reader - NewsGator is specific to Outlook, so I won't pay them $29.

mail aggregator code

2003-03-07T14:07:00.000-08:00

I cleaned up a bit and uploaded my mail aggregator. Getting rid of the pickle was a great move - db seems good enough.

For now I use simple name-value mappings and several db files - it's easier to debug and get other tools to use the same data. I was thinking of a real database - but that would make it more complex and I doubt it'll scale or work better.

I doubt too many people will find it usefull - when they have all the fine 3-panel graphical agreggators. I just use it to read weblogs in train, using my old "pine" and sometimes mozilla/evolution/kmail ( when I feel a need for real nice GUI - and go back to pine when I want to read mail ).

HelloWorld - finally !

2003-03-07T07:28:00.000-08:00

Last night I got the first "hello world" page from tomcat5/JMX. No server.xml, no fat, only a small set of mbeans driven by ant. Things were very close for a while but never quite work completely. There is still a lot of work, mostly downhill IMO.
I can't wait to finish - I'm in overload mode for some time, doing too many things at once.

JMX clustering

2003-03-01T22:21:00.000-08:00

I don't like session clustering for a lot of reasons. Clustering in general is great - but the servlet session API just doesn't have enough power to allow a correct and efficient use of clustering. The use case for caching some values is compromised,
there is no transaction support, no feedback or control - users are much better served by assuming the session is transient, and using database or user-controled clustering.

By clustering I understand broadcasting and mirroring some data on multiple instances - there are many other meanings. It is a very powerful tool if used right.

There is one use of clustering that would be extremely intersting - broadcasting and clustering the JMX attributes. The idea is to have a global view - each tomcat instance could brodacast its mbeans and attributes, and may be able to take more inteligent decisions knowing the state of the other instances. And the admin console would get info from all instances.

JMX console

2003-02-25T23:58:00.000-08:00

One of the main benfits of JMX is the ability to "see" what happens at runtime and to tune the process. The admin interface is good, as it provides a nice interface - but for advanced use you need a low level console. Each JMX tool has its own console - and that may be a bit confusing if you switch them often.

An interesting fact is that most of the consoles can be used with other JMX implementations - with almost no effort. That's a pretty good proof of the benefits of low coupling.

The JBoss console is a webapp - you'll need to copy jboss-client.jar and log4j.jar in WEB-INF/lib, since it's not self-contained ( there are few utils for logging ), but besides that you should be able to use it with any servlet container that has JMX support. It may be worth precompiling the jsps.

MX4J doesn't depend on a servlet container - it uses an interesting ( but slower ) XSL and its own HTTP listener. All you need to do is load the mbeans. Commons-moder provides a one-line mechanism - I'll comment on it later ( I'll do few more enhancements and simplifications ).

JMX-RI has the fastest console - also contain its own HTTP listener and is packed as few mbeans. I have no idea what's inside - so I usually preffer one of the other two.

Another note - in tomcat ( any - if it uses jk2 and coyote ) you can just add a "mx.port=PORT" in jk2.properties and MX4J or JMX-RI console will be started. You need to copy one of the 2 in server/lib ( mx4j-tools.jar or jmxri-tools.jar ). If mx4j is used, it'll also try to enable the RMI connector. Most of the code will fail gracefully, without affecting the rest. The startup time overhead is quite small.

Sending mail to the blog

2003-02-22T23:58:00.000-08:00

Armed with Sam's short intro and the MT manuals - I started the second piece of my mail toy - weblog posting via email. Posting via xmlrpc is much easier than I expected - it took me a while to figure what is the blogid, but after that everything was smooth.
I'm using the metalog xml-rpc style - and I'll use the mt extensions to set the category.

One comment on Sam's "REST" alternative - I think an even better approach would be WebDAV, with the item body as plain HTML, with META tags used for the category and the extra (meta) info. This way all HTML editors would be able to edit and publish weblog entries without any modifications. WebDAV also allow editing existing entries. The "core" of a weblog entry is a piece of HTML - with extra metadata and with extra processing done to generate the weblog-style pages ( templates to generate rss, html in a specific layout, etc ).

The next item to implement is the wiki filter, so I can use pine to send wiki-style plain email and have it converted to html that I can upload via xmlrpc. The real hard part will be implementing the special "headers" for meta-info, and implementing the "special" posting forms ( comments to other postings and about web sites ). I want to just use the "mail this page" button, add the comments on top and send it to "myBlog@myDOMAIN.com".

Back from traffic school

2003-02-22T16:19:00.000-08:00

Boring - but I got 8 hours to think about other things. Like where to put the extra information that is required to weblog by email. The logical place would be in headers - but most mailers don't make this easy, and it would be confusing to some people. In addition - if you do "send page" in a web browser, and you want to comment on the page ( a very nice way to enter this kind of weblogs ) - you have an even less functional mailer.

Another option would be the recipient address - it can be myBlogPostinEmail+extra-infor@domain.com. Unfortunately - the "+" syntax is not supported by most domains, and it assumes you are in control of the mail system - which would work great for a "mail to weblog" provider, but not that well for individual use.

So - the remaining place is the top and bottom of the post. Each post will start ( and be parsed for ) a set of "magic" headers - headers inside the body and at the end, after some -- that indicate the signature. Some mailers allow to associate a signature with a particular address - that would work pretty well.

What meta-information is required ? First, a "key" - the preffered mechanism would be to sign the message, but again one of the target for such a system is people who don't want all the technical complexity of a new application.
The other info is the "category", and also some address to send talkback to ( this can be extracted from Reply To: if a mail-based "agregator" is used to read the weblogs ).

Is this too complicated ? I don't think so, people are used to start the mails with a "Hi" and with many kinds of "forms". I think there are also "mail templates" that could help.

HTML mail would be more difficult to parse for that - but it's not impossible ( just need to look for the magic keywords delimited by < and > ).

Wiki, Weblog and Pine

2003-02-20T07:38:00.000-08:00

It seems I'm not the only one - James Strachan wants to use a WYSYWIG editor for wiki.

The main point of wiki is the ease of authoring. Well, learning a new set of rules (slightly different for every wiki ) and editing it in a HTML form is not "easy" by my definition.

Some web browsers have a nice menu option - "Edit this page", and you are presented with a decent HTML editor. Of course, it generates crappy HTML, but it's easy to filter it out to the same level as wiki ( i.e. only simple tags with no style attributes ). And then - you can either "publish" ( again, widely available ) or just "mail" - so you can do your stuff offline.

I see a lot of value in the wiki style - but _one_ style, chosen by the author and not by each site. And used when the author preffers to use a text editor ( a decent one - not a form ) - like pine or vi or emacs. Again - "mail this" is so trivial and available in so many editors.

As you have noticed - I am not happy with the current model for "agregators" and "authoring" for weblogs. For exactly the same reason. Even if they will create an intuitive and easy to use agregator and authoring tool ( and I heard they're not ) - why should people have to learn and install another tool ?

Last days I tought about this - as my "mail agregator" is growing and I am moving to the publishing side, I'm prioritising the list of features. Composing a weblog using wiki style from pine is very high - since I use pine a lot. I also use Evolution
or Mozilla from time to time - so authoring weblogs in one of those and publishing it via a simple "send email" is the second priority.

Back to wiki - the fundamental idea is to be VERY simple. Using a familiar tool is simpler. It is harder to implement the wiki ( you need to enable webdav or some mail filters, better locking, convery ugly html to wiki or simple html, support multiple editors, etc ).

First problem with mail blogs

2003-02-18T08:01:00.000-08:00

I was parsing the Cafe Con Leche rss feed. No explicit date - that becomes ususal. Only the day can be extracted from the link reference. The real problem - only "description" is available for items,
with a short exceprt - and the link points to the day view, not the individual item.

Initially I was thinking to use a workaround for "description only" or "incomplete content" - i.e. grab the linked item. Unfortunately the link is not to the article, but to the page containing a list of articles and a lot of other markup and stuff.

Mail aggregator

2003-02-16T21:12:00.000-08:00

My mail aggregator is working fine - thanks Sam for the 2 pointers. The big problem is of course the "standard" XML/RSS that is used. Just like in almost all other places where XML is used - the benefit of a standard syntax is countered by the complete random and obfuscated ( and countless) schemas and variations.

First problem: many feeds don't include the date - I added few regexp to extract common patterns ( Updated: ..., Posted: ... ) from the content. If I can't get it - I'll assume the time of the collection - which would be wrong for older news, but it'll be close enough as I update.

Second problem: Since most of the time you can't tell if a "permalink" has been updated - I have to cache the MD5, so I get new mail when the link content changes.

What's next ? One think I allways liked is the multipart mime - with HTML and images in the same message. I don't remember the details ( the links have special syntax ), but it shouldn't be difficult to fecth the images and save them with the entry, for full off-line reading. And the other side - using mail to update my own
weblog.

I expect more tweaks as I read more weblogs - each weblog I add has its own (standard :-) XML style.

BTW, I (re)discovered the "trick" to include the images in the mail - the program will need to grab all , add the content as mime parts and use "cid:" magic protocol, and Content-ID header in the parts. It shouldn't be very hard to code - but for now it's not a big priority, the mailer can get the images from the web when online and only few weblogs have images.

mail and weblog (3)

2003-02-12T22:27:00.000-08:00

Finally, reading weblogs starts to become easy. I modified blagg - actually rewrite it in python, I'm clearly out of touch with perl. I generate the files in maildir format, then I use KMail to read it. I usually use pine, but pine requires some patches to support maildir and it's not that nice with HTML.

There are many details to sort out - I can parse only 2-3 .rss formats so far, but the benefit is huge. I need to get the comments and fix the headers so I can see them as threads, and I'll like to do a simple scan on the content and get the images - and generate the multiplart MIME message.

The big one is getting the category and sorting in folders - but that can be done in procmail. I'm trying to preserve all the RSS data as mail headers - so procmail can do its job.

In any case - even with the ugly hacky script I'm using, KNode ( or pine or Evolution or mozilla - after I get procmail I can just push the items in regular imap ) are so much better than any of the agregators I've seen so far. Sorting, offline read, filtering, organizing data and moving interesting items in the same folders I use for interesting mails - and above all, the "familiar" feeling and having all the keys in my fingers...

The other direction is also interesting - editing HTML mail in any mailer ( offline or not ) and then having it published as a weblog entry.