This has been on my list of things to think about for some time, but I haven't
gotten to it yet.
I think it should be possible to subclass the existing IMAP provider code to
create a "gimap" provider, without the need to fork all of the JavaMail code.
It may be necessary to enhance the base classes to make this work but that would
definitely be worth considering.
If you're interested in pursuing this yourself, please see the JavaMail
Contributions page <
http://kenai.com/projects/javamail/pages/Contributions>.
One of the reasons I haven't pursued this myself yet is that I'm still trying to
decide if this is the best approach. In some ways it would be easier to just
build in the Gmail-specific features to the base IMAP classes. It's not as
clean, but GMail is so widely used perhaps it's worth it?
Yet another approach is similar to what I think you're suggesting. The base
IMAP classes could be enhanced not with Gmail-specific support, but with more
general extension points, which people could use to access Gmail-specific
features. That might make it a bit more clumsy to access those Gmail features,
but the extensibility might be useful for accessing product-specific features in
other products as well.
So I guess I see three options:
1. Build in Gmail-specific features
2. Make it easy to create a provider with Gmail-specific features by
subclassing the existing IMAP provider
3. Make it easier to access product-specific features using the existing IMAP
provider
I was leaning towards #2, but I see the advantages of the others as well. I'd
have to look into the details of the Gmail-specific features to see if #3 is
feasible.
Zsombor wrote on 7/22/12 11:17 AM:
> Hi,
>
> Have you ever considered making the IMAP fetch command handling a bit more
> extensible ? I mean, you probably aware, that gmail imap supports a couple
> flags, which can be queried with a regular fetch command. Unfortunately this
> doesn't work:
>
> FetchProfile fp = new FetchProfile();
> fp.add(GMFetchProfileItem.MESSAGE_ID);
> folder.fetch(messages, fp);
>
> where GMFetchProfileItem.MESSAGE_ID is a custom FetchProfile.Item.
> It seems a common issue, because there is a javamail fork (
> http://code.google.com/p/java-gmail-imap/ ) to address this shortcomings.
> However, it's a google specific code, I can understand, that you don't want to
> implement inside the core IMAP code. But I think, it is possible to implement
> the necessary framework, so any user can write his own plugin, so no forking
> will be needed for any custom flags. Will you accept this kind of patches into
> javamail? Is it worth working on ?
>
> Thanks,
> Zsombor
>
>
>
>