Hi Kevin,Thanks Steve, yes, of course it's the community's.
Its great that you are interested in contributing. Here's some quick
feedback which I hope helps. Remember, its not my fetchmail stuff, its the
community's, and these are just the views of one member of that community.
I'm not sure why you wouldn't want to fetch mail outside of business hours,<snipped>
but technically this is a good idea. Personally I would tag it so everything
was kept together like this...
Mainly it's a business requirement. I fetch email sent to our support mailboxes, and one of the actions my processing takes is to send a response.back to the customer. The email mentions resolution times, which is related to support contracts, which means I can't send emails if no one is going to look at the customer's request immediately.
Anyway, your points make sense and I'll take them into account.
I realized my wording was incorrect. It wouldn't obsolete <fetchall>, but this would alter the behavior of fetchall because the filter would change the subset of messages that is later subject to the <fetchall> setting.2) FetchMail search terms.
<snipped>
<fetchfilter> would effectively obsolete the <fetchall> option.
Not without provision for changing the mail state to delete of seen, otherwise there is no way to avoid processesing the same messages over and over.
Ah yes, the power of someone else looking at yuor work--I went crazily overboard with my fetchfilters. I adapted every single subclass of JavaMail SearchTerm without thinking if they'd be useful. Some of these are useless.In most use-cases, wouldn't "Simple date" need to be dynamic or expressed as an offset such as 30 days ago?
I did realize that at one point, and I was thinking of providing FetchMail a list of Matchers to allow customization to that detail. But beyond the fact that that was a bad idea on several levels ;), in the end, my only requirement is that I must NOT fetch any emails that were sent to the mailbox by my application ( it sends an email back to "itself" which specifies the status and result of the customer's email). These emails are identified with a known subject.prefix. And so a simple subject regex in fetchmail would suffice. The other fields and the <and><or> logic was fairly easy to implement, so I did it., in case someone needs to filter by a headert. But as mentioned above, some are superfluous.Personally, I feel that generalised mail processing of the type you propose should be left to James' mailet chain. Otherwise, where do you stop? Before we know it, someone will realise that however many filters we add, there is always a new requirement and propose that we add a pluggable message processing structure into fetchmail, ie: mailets! As we already have this in James we don't need it elsewhere.
<snipped>
The filter would only be applied if present. If not, there's no hit to performance and none of the msg body is fetched unnecessarily. When applied, it's up to the JavaMail Folder.search() implementation to find matching messages. For example, if were are using an IMAP server and filtering on subject, only the message envelopes would be retrieved from the server.In fact, next up in my to do list is to switch to using an InputStream when the message delivered into James is created so that we don't EVER touch the message body in fetchmail. This will be defeated if we start checking the contents or size of the message body.
Hopefully I've explained why this can't be a matcher... but it could be scaled down to a smaller set of search terms... namely: subject, header, recipientstring, recipient, from, fromstring. Or just a subjet filter if the other filters would have no use in the 'real' world.As you have probably gathered, I'm personally not taken by the idea of adding this to fetchmail. It would make a useful matcher though.
Hadn't heard about this yet... I'll take a look if you have it handy.It is already possible to pass search terms such as this to a matcher, if somewhat cumbersome. The scripting support added by ScriptedMatcher does this. Unfortunately, it hasn't made its way into head yet, but I would be happy to send you the code to examine.
<snipped>
I use Intellij Idea Aurora, which doesn't appear to have that ability. Looks like I'll stick to command line for now...Lastly, I'm a bit naive when it comes to CVS and creating diffs for
patches.
<snipped>
I develop in Eclipse and use its Patch creation facility. This works well except for a bug when including new files in new directories in the patch (so don't). Be sure to configure the Eclipse editors to use spaces instead of tabs and Unix line delimiters. You might want to post this, and the restart question seperately so you get the views of others who have no interest in fetchmail.
I hope this helps.
Cheers,
-- Steve
Immensely. Thanks for your time! Kevin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
