William Morgan, 2011-02-21 23:02:
> I have been making a lot of
> progress in a short amount of time.
Cool! I'm thrilled. \o/
> - Precompute threads, so that search requires only moderate effort,
> instead of the large effort it does now. This will make search
> much, much faster, at the expense of a little more effort at index
> time.
I guess this offers the possibility to add threading to "external
state" of messages, together with labels. I'd do a whole a lot of
more prune'n'crafting with my threads if there only was more
comfortable interface to doing it (admit it, been too lazy to
implement it in sup).
Do you have considerations wrt to programmatical thread browsing and
editing API? Something I've thought of, on the top of my head.
first_msg
|-- second_msg
|-- third_msg
| `-- fifth_msg
`-- fourth_msg
sixth_msg
`-- seventh_msg
thread = Thread.find :second
subthread = thread.find { |msg| msg == :third_msg }.prune!
Message.find(:sixth_msg).craft! subthread
first
|-- second
`-- fourth
sixth
|-- third
| `-- fifth
`-- seventh
> - Allow concurrent access from multiple clients.
Since the first post on sup-server I've been nurturing the idea of
"fat" sup-client for maemo/meego.
> - Borrow as much code as possible from the current Sup, because I
> sure as shit don't want to have to rewrite it all.
Would it be time to go for https://github.com/mikel/mail now? It
would be supported and actively developed and I really like the API.
As a downside, depending on activesupport pulls in a whole a lot of
fluff and using treetop may suggest that parsing might hog a little
more cpu and memory than is absolutely necessary.
Who would give us bindings to GMime and wrap it inside Mail API...
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel
