<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span><br></span></div><br><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div class="y_msg_container">
On Wed, Sep 4, 2013 at 2:48 PM, Eygene Ryabinkin <<a ymailto="mailto:rea@codelabs.ru" href="mailto:rea@codelabs.ru">rea@codelabs.ru</a>> wrote:<br>> Wed, Sep 04, 2013 at 09:25:15AM +0100, Nicholas Cole wrote:<br>>> On Wed, Sep 4, 2013 at 9:13 AM, Eygene Ryabinkin <<a ymailto="mailto:rea@codelabs.ru" href="mailto:rea@codelabs.ru">rea@codelabs.ru</a>> wrote:<br>>> > If you'll try to explicitely describe what you intend to do, may be<br>>> > it will be more clear how and if we can help you with that.<br>>><br>>> Sorry for not being clear. I'd like my users to enter their IMAP<br>>> details in my application, and to use OfflineIMAP to maintain a local<br>>> cache of the IMAP account that is then synced with the IMAP account,<br>>> without my users ever being aware that they are using OfflineIMAP at<br>>> all.<br>>><br>>> My main application would no doubt need to
check for dropped<br>>> connections and other errors, and manage all the configuration and<br>>> operation of OfflineIMAP. So I guess what I had in mind is embedding<br>>> OfflineIMAP into another product. What I don't want my users to have<br>>> to do is worrying about configuring OfflineIMAP themselves, or<br>>> starting and stopping it. I'd like it to be entirely transparent to<br>>> the user. I assume that there are different ways of achieving<br>>> this....<br>><br>> OK, this makes the situation more clear. I think that currently you<br>> can use OI as the stand-alone utility that is working either in daemon<br>> or one-shot mode. It seems to me that programmatically invoking some<br>> parts of OI isn't a way to go for now, because there are no API<br>> guarantees apart from configuration and command-line keys/arguments<br>> that are to be remain
supported on a long term basis without changing<br>> their names or semantics every now and then.<br>><br>> I don't know how large is your userbase and how far you want to go<br>> into the land of optimizing the whole application, but probably you<br>> can start with using OI in one-shot mode and doing periodical syncs<br>> by invoking OI each time. This will create some load on the system,<br>> because of startup issues, on the other hand, it will eliminate some<br>> problems of coping with OI daemon persistence (and I expect some ;))<br>><br>> What is currently lacking is well-defined error codes that tells you<br>> which kind of problem occurred. There is even a semi-related ticket,<br>> <a href="https://github.com/OfflineIMAP/offlineimap/issues/31" target="_blank">https://github.com/OfflineIMAP/offlineimap/issues/31</a><br>> but I am currently not up to solve this problem fully due to
somewhat<br>> limited amount of time and more general need to bring OfflineIMAP to<br>> the good shape to roll out the next release. Though if someone will<br>> coin in patches and/or code refactoring -- it will be very good.<br>><br>> I think that you're the first one who may be need the stable Python<br>> API for performing OI operations, so the concrete needs and work<br>> effort will be driven by you. I will be very happy (if the time will<br>> permit) to help with implementing new features, API, etc, but this<br>> should be supplemented with the real need for that. May be your case<br>> won't need stable Python API and OI as the external utility will work<br>> fine, but you will need something else (more stable operations, some<br>> additional features, etc).<br>><br>> In my view, it will be very good to have such project that uses OI as<br>> the backend, because it will provide some
testing ground for<br>> OfflineIMAP and might even bring in more developers -- the stuff we're<br>> currently in a rather big need.<br>><br>> So, try to come up with the way you will use OI, prototype it, ask<br>> questions, fill bugs, submit patches.<br>> --<br>> rea<br><br>>Thanks for all of that. That makes everything much clearer from my<br>>point of view too. You are are right, I had been using OfflineIMAP in<br>>daemon mode, but perhaps that isn't appropriate for what I have in<br>>mind. You are right, I had been worried about checking whether the<br>>daemon was still active, whether it had encountered errors etc.<br>>One-shot mode may well be good enough for what I need. I'll<br>>experiment. The project I'm working on will be Open Source, assuming<br>>I can get around one or two issues with that, so I'll share progress<br>>as I go along.<br>><br>>N.<br><br>Interesting-
OI as a component - <br><br>Are you wanting to embed it inside of a system admin app? User friendly automation of email replication, backup and archiving tasks? <br><br>What about the lambda expressions, and reverse-lambda expressions - for the mailbox name mapping ?<br><br><br></div> </div> </div> </div></body></html>