Using Offline IMAP in a larger project

[Eygene Ryabinkin]

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