Using Offline IMAP in a larger project

[Nicholas Cole]

On Wed, Sep 4, 2013 at 2:48 PM, Eygene Ryabinkin <rea at codelabs.ru> wrote:
> Wed, Sep 04, 2013 at 09:25:15AM +0100, Nicholas Cole wrote:
>> On Wed, Sep 4, 2013 at 9:13 AM, Eygene Ryabinkin <rea at codelabs.ru> wrote:
>> > If you'll try to explicitely describe what you intend to do, may be
>> > it will be more clear how and if we can help you with that.
>>
>> Sorry for not being clear.  I'd like my users to enter their IMAP
>> details in my application, and to use OfflineIMAP to maintain a local
>> cache of the IMAP account that is then synced with the IMAP account,
>> without my users ever being aware that they are using OfflineIMAP at
>> all.
>>
>> My main application would no doubt need to check for dropped
>> connections and other errors, and manage all the configuration and
>> operation of OfflineIMAP.  So I guess what I had in mind is embedding
>> OfflineIMAP into another product.  What I don't want my users to have
>> to do is worrying about configuring OfflineIMAP themselves, or
>> starting and stopping it.  I'd like it to be entirely transparent to
>> the user.  I assume that there are different ways of achieving
>> this....
>
> OK, this makes the situation more clear.  I think that currently you
> can use OI as the stand-alone utility that is working either in daemon
> or one-shot mode.  It seems to me that programmatically invoking some
> parts of OI isn't a way to go for now, because there are no API
> guarantees apart from configuration and command-line keys/arguments
> that are to be remain supported on a long term basis without changing
> their names or semantics every now and then.
>
> I don't know how large is your userbase and how far you want to go
> into the land of optimizing the whole application, but probably you
> can start with using OI in one-shot mode and doing periodical syncs
> by invoking OI each time.  This will create some load on the system,
> because of startup issues, on the other hand, it will eliminate some
> problems of coping with OI daemon persistence (and I expect some ;))
>
> What is currently lacking is well-defined error codes that tells you
> which kind of problem occurred.  There is even a semi-related ticket,
>   https://github.com/OfflineIMAP/offlineimap/issues/31
> but I am currently not up to solve this problem fully due to somewhat
> limited amount of time and more general need to bring OfflineIMAP to
> the good shape to roll out the next release.  Though if someone will
> coin in patches and/or code refactoring -- it will be very good.
>
> I think that you're the first one who may be need the stable Python
> API for performing OI operations, so the concrete needs and work
> effort will be driven by you.  I will be very happy (if the time will
> permit) to help with implementing new features, API, etc, but this
> should be supplemented with the real need for that.  May be your case
> won't need stable Python API and OI as the external utility will work
> fine, but you will need something else (more stable operations, some
> additional features, etc).
>
> In my view, it will be very good to have such project that uses OI as
> the backend, because it will provide some testing ground for
> OfflineIMAP and might even bring in more developers -- the stuff we're
> currently in a rather big need.
>
> So, try to come up with the way you will use OI, prototype it, ask
> questions, fill bugs, submit patches.
> --
> rea

Thanks for all of that. That makes everything much clearer from my
point of view too.  You are are right, I had been using OfflineIMAP in
daemon mode, but perhaps that isn't appropriate for what I have in
mind.  You are right, I had been worried about checking whether the
daemon was still active, whether it had encountered errors etc.
One-shot mode may well be good enough for what I need.  I'll
experiment.  The project I'm working on will be Open Source, assuming
I can get around one or two issues with that, so I'll share progress
as I go along.

N.