well, right now a new potential point of focus for the framework will probably be some sort of integration with the contacts
 for example: give me a list of e-mails (and maybe also subject-threads) where this contact was involved
 which is not a TnyFilter thingy, indeed
 more a search thingy
 but filtering is something device vendors are asking, yes. But as a low priority item
 especially anti-spam and serverside filtering
 anti-spam also locally, but preferably at serverside too: bandwidth 
 if the spam got on the local mobile device, it's actually too late. Money on the GPRS bandwidith is wasted
 that's why I liked your Sieve proposal
 maybe some tnyfilters that will detect and install/configure serverside anti-spam solutions
 or support some simple rules like: block this person on the server
 it can of course be an entire framework for this that is not related to tinymail, and an implementation of TnyFilter that consumes that framework
 but with such filtering features, the free mobile world would have a significant selling point when competing with for example the Blackberry world
 and it's in the end just integrating existing tech
 "getting it right"
 anyway, I'm going to bed now
<pvanhoof> wasabi_, if you are interested in that (I remember that you once asked me about filtering, right?) .. maybe a nice thick analysis of all this on the wiki
<pvanhoof> I can work on this too
 and perhaps I can talk with some 'people' :) about wrapping the ideas into bounties
 else it'll be waiting for a sponsor I guess :)
 or for nokia to make it a focus for my work for them
<wasabi_> reading all that
 That contact thing. I actually have some opinions on it.
 I've talked with... um.... Chip, and Carlos with Nokia, at UDS-MTV last year.
<pvanhoof> well, make a wiki page
 this is or would be for openmoko
<wasabi_> You may have noticed, but I don't have the time to go off and spruce up a wiki page. ;)
 Just randomlly dump ideas on IRC.
<pvanhoof> I haven't yet had this requirement from nokia's modest team
 yes, copypaste them to wiki pages in stead :)
 and dump wiki URLs here
 a wikignome will improve the layout, don't worry
<wasabi_> okay, so, at UDS-MTV carlos expressed concerns with galago, which seeks to sort of address this problem... you know about galago?
<pvanhoof> yes
 some integration with galago will happen soon
<wasabi_> Basic idea is a daemon that takes information about people advertised from various places, merges it all on various points, and returns it.
 So you can see Bob is on IM and also whatever.
<pvanhoof> yes
<wasabi_> I think Galago is overkill there, and not really neccassary.
<pvanhoof> well, the feature is more to get a work-log of a person
<wasabi_> And so did carlos. Galago ate all the ram.
<pvanhoof> including its email
 s/its/his
 probably just a small improvement to make it stop eating ram
<wasabi_> Instead, I'd rather all programs which had knowledge of a human being had the capability to a) broadcast all of their knowledge b) be asked to broadcast all of their knowledge.
<pvanhoof> but anyway, the feature is just a search. Doesn't have a lot to do with galago specific
<wasabi_> The information broadcasted would be some super/sub/something set of VCARD... name value pairs of information that the service might know.
<pvanhoof> well, galago expects a unique something about the person
<wasabi_> Along with a DBUS object id that can be used to refer to the information.
<pvanhoof> usually the e-mail address
 which I of course can give to it
<wasabi_> So, when somebody logs onto your IM, you'd get a bunch of dbus broadcasts describing who was on the IM, and the information known. jabber id, aol name, whatever.
<pvanhoof> it'll return me a person object that contains this info about that person
--> ceyusa (~ceyusa@proxysb02.ext.ti.com) has joined #tinymail
<wasabi_> Any apps that cared could listen to this information, and match it against their own information.
<pvanhoof> or a list of persons if I gave it a query
 using that info I can show for example the online state of the dude in the email client
<wasabi_> So, the lifetime of the data is only when it's needed. After that it's gone.
<pvanhoof> and make that a button
 that opens an IM window when pressed (that's mission control in action)
<wasabi_> And you end up with this web of dbus object id's being built. TinyMail has an email from bob@joe.com.... and it received a broadcast that bob@joe.com is logged into IM.
 So it can store and remember that.
 And like wise, the IM client knows that tinymail has information for bob@joe.com
<pvanhoof> uhu
 yet all that is simple and not so much related to this feature
<wasabi_> But all that is really stored long term is the two associated objectids, and whatever private data the apps had anyways.
<pvanhoof> the feature is basically showing what activity the dude caused
<wasabi_> Hmm.
<pvanhoof> like emails, IM logs, etc etc
<wasabi_> What I mean by this, is when you talk about integration with "contacts"
<pvanhoof> so another application will make a query to tinymail about the emails he caused
<wasabi_> maybe that's not what you should implement. Implement integration with 'various advertised information bits', not any particular "contact" idea. Don't go querying E-D-S.
<pvanhoof> no, they will integrate with for example eds to get the list of contacts
 and with tinymail to get the emails for the person
 and maybe will tinymail integrate with that other application to have a completing textbox when you are writing a new message that needs to be send
 for the To field
<wasabi_> Yeah, that's sort of what I mean. tinymail can broadcast a search over dbus for whatever the user is typing on the VCARD EMAIL field.
 And various applications can respond. One of which might be E-D-S
<pvanhoof> usually, only one will be active though
 it's a mobile, not a desktop with KDE and GNOME being active
<wasabi_> E-D-S and an IM client could certainly be both running at the same time.
 Even on a phone.
 In fact, particularily on a phone.
 I'm not turning my IM client off to write an email. :0
 It tends to just... go in the background.
 Without any sense of being started or not.
<pvanhoof> well, on mobiles its not uncommon that the IM client also uses eds
<wasabi_> So the basic idea is to define a set of fields to describe a contact, email being one of them, and a DBUS broadcast interface to query for matches.
<pvanhoof> and integrates directly
<wasabi_> Okay... well.. whatever.
<pvanhoof> if it's eds, because some vendors have their own data service :)
<wasabi_> Well, it might not completely concern you, but my idea has desktop merit too.
 It basically replaces galago.
<pvanhoof> I'll watch you :)
 give me a call when its finished !
 by the time it is, over VoIP probably :)
<wasabi_> One more project that I'll never actually do, but thought up on a train ride home or soemthing.
<pvanhoof> anyway, good luck with the idea. But right now I'm going to sleep