Notification: Extending "My Mail" plugin (2 Viewers)

[coolsurfer]

feature request:

is there a chance to add IMAP support ?

coolsurfer

 

[bigj]

> COuld you write the login name and password in the XML NOT IN PLAIN TXT

I'll look at this.

> is there a chance to add IMAP support ?

Don't know - the way I'm reworking it, it should be possible to add multiple providers of any type pretty easily, so if I don't add IMAP then I'm sure someone can


I should stress that progress is slow just because my time is limited, but it is progressing.

I welcome any other ideas/requests - just append them to this thread and it will serve as a good reference.

Cheers,
BigJ.

 

[A Frater]

Number 2 for me would like to delete mail that has been read either manualy or as you exit into the home screen .

 

[~ok|]

hi,

bigj
is it still a work in progress or did you stop playing w/?
I had plans to remake the original Agree's plugin in my spare time, but 1) I don't want to reinvent the wheel and 2) undermine/undo/slow down any of your previous work w/ a competing plugin.

If I were involved in a developement on my own, I'd focus on (in order):
1) Thread-safe e-mail retrieval & concurrent mailbox connections
2) e-mail message management (SQLite if constraints fullfilled from 1) )
3) Feature set extension (i.e. IMAP support is my only aim ATM)
4) User notification (ala My MSN Messenger)
in fact pretty much what you exposed above (except the regexp filter part)

So what is the status of your new plugin? May I help you?

cheers

 

[bigj]

hi,

bigj
is it still a work in progress or did you stop playing w/?
I had plans to remake the original Agree's plugin in my spare time, but 1) I don't want to reinvent the wheel and 2) undermine/undo/slow down any of your previous work w/ a competing plugin.

Hey <ok|, I guess I'd have to say it is stalled at best! - I've had even less time than anticipated and its only going to get worse over these next few months as we're hitting a crunch at work.

If you are happy to pick this up then go for it! I've uploaded my sources which you are free to continue with or ignore as you want!

http://www.topflat.charitydays.co.uk/mp/messaging/MESSAGING_MERGED_9_JULY_2006.zip

If I were involved in a developement on my own, I'd focus on (in order):
1) Thread-safe e-mail retrieval & concurrent mailbox connections
2) e-mail message management (SQLite if constraints fullfilled from 1) )
3) Feature set extension (i.e. IMAP support is my only aim ATM)
4) User notification (ala My MSN Messenger)
in fact pretty much what you exposed above (except the regexp filter part)

So what is the status of your new plugin? May I help you?
cheers

It sounds like our aims are similar.
My sources are stripped down/refactoring of mymail. Now called MyMessages.
My ambition was to have a common messaging plugin that could be extended to support any number of 'providers'. It was to make adding new providers really simple since all the GUI, Database, Notifications etc should be common.
My zip includes my stubbed out class design, I added a message database and config loading for abstract provider. I was starting with the pop3 provider - began moving over agrees mymail implementation code.

The code I have kicks off a timer thread for each provider at low priority and would every N seconds retrieve new messages.

There is a ComplexMatch class there I wrote which will do filtering on multiple fields. (strings only atm, but was to be extended to numbers, dates etc). It supports REGEXP. Expressions of this sort can be written:
((PROVIDER IS POP3) AND (SENDER CONTAINS "Bob"))


My idea was that all messages (from all providers) would get put into the single database.

Providers would be defined via the MP config app:

MyMessages Setup:

-Add Provider:
***********************
--Generic Params:
---Message Count (so only newest N messages from each provider are held in the DB).
--Specifiy Type (eg POP3)
---Type Specific Params: Server etc.

-Add Folder(View):
***********************
--Folder Name
--Folder FilterString (for ComplexMatch).
--Notify? (on/off)
--Notification Count (so every Nth message that qualifies for this folder triggers a GUI notification popup).


A single message can match zero, one or more filters (folders). The folder's filter is run on each message as it's retrieved from the provider and a bitmask of matched folders is created and stored with the message in the database. It's then easy at viewing time to determine which messages match a specific folder view.

Supporting user defined folders via filterstrings allows for rich expression of views. Regular (common) views such as 'Not Read' can be added via this too. Users can dump all messages from all providers into a single folder or have folder per provider, per sender, per receiver etc etc

The notification count is used so that high-frequency folders don't keep swamping the user with popups.

The provider message count is used so that user doesn't have to worry about deleteing messages - the database is self-trimming - it's just a 'cached view' onto the newest messages (from each provider).

Other provider types (these exist as multiple plugins, but my hope was that if a single abstract messaging plugin could be show to work (for pop3) that these would be integrated here.):

- Forums
- SVN Checkins
- GMail
- MSN Messager
etc

The interface with the Provider resolves to something as simple as:

IProvider::RefreshNewestMessages( int count )

How a provider gets its messages is an implementation detail (provider specific).


Hope all this makes sense - none of it is that complicated, but I think would provide for a really powerful and flexible yet consistent system.
As I say feel free to ignore my ramblings/ideas!

Cheers,
BigJ

 

[~ok|]

I began reading your work and I like it (thanks for the README.TXT and the well commented code ). I will continue working on it and try to get fully compliant POP3 and IMAP providers ASAP. However do not get too eager reagrding the schedule as I'm only able to code in my idle time on saturdays (yes it is as short as it sounds) and I want to rewrite from scratch the mail client part (or at least get rid of the limitations of the actual implementation).

Ask for the WIP code at anytime if you think I'm too slow and you'd like to help

 

[~ok|]

The plugin is a little bit slow to come but the development is not halted.

DONE: Common architecture completed and/or extended. Ready to encapsulate real Providers
TO DO: Implementing a POP3 Provider (at first and because it's the easiest to handle), will redo Agree's work where needed.

I'm still wondering if it'd be better to store every messages from a message box in the database or the newest ones only (real messaging system vs notification-only client). Obsolete message trimming and detection of unnecessary update of content *should* be fast enough not to care about these specific points.

 

[zombiepig]

hey <okl - just wanted to say keep up the good work!! i for one think this plugin will make a great addition to mp and sounds like it will end up being very flexible and powerful.

 

[reagan+carter]

No change for more than a month but the development has now resumed.

Almost every core components have been completed, including working (and RFC compliant) POP3 and IMAP 4.1 implementations (so relieved it's over).

Still no early alpha to expose. A lot of work has yet to be done.

DONE TILL LAST POST UPDATE:
1) Database - Provider interface
2) Provider GUIs
3) Database - Message interface
4) Message Management/handling by Provider

TODO:
5) Basic Message GUIs
6) Options available through the main GUI
7) POP3 extensive testing

I will update this post with the WIP status ASAP.

see you.

 

[aggi]

any news!

any chance to read, write, answer and delete???