Using Squirrelmail IMAP Core

[Daniel Watts]

Dear Devs,

I am pretty sure a while ago I saw someone who was talking about the
squirrelmail imap handling layer in his own application. Presumably
because they can then rely on a imap library that is maintained by some
mail experts (you!).

We're trying to do this ourselves but have found there is a whole bunch
of stuff (eg in imap_general.php) that is non-imap - eg calls to
creating error boxes and use of global language variables.

These require certain other webmail related files to be required which,
of course, is added overhead.

Do you have available anything/anymethod that doesn't require these
extra includes? Or do we just need to go through and strip out anything
that isn't directly related to interfacing with imap?

Many thanks!
Daniel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

[Paul Lesniewski]

On Mon, Jan 26, 2009 at 7:22 AM, Daniel Watts <d@...> wrote:

> Dear Devs,
>
> I am pretty sure a while ago I saw someone who was talking about the
> squirrelmail imap handling layer in his own application. Presumably
> because they can then rely on a imap library that is maintained by some
> mail experts (you!).
>
> We're trying to do this ourselves but have found there is a whole bunch
> of stuff (eg in imap_general.php) that is non-imap - eg calls to
> creating error boxes and use of global language variables.
>
> These require certain other webmail related files to be required which,
> of course, is added overhead.
>
> Do you have available anything/anymethod that doesn't require these
> extra includes? Or do we just need to go through and strip out anything
> that isn't directly related to interfacing with imap?

There is not anyone I know of using the IMAP code separately for
exactly the reason you found.  Doing what you are trying to do is part
of the work needed to abstract that code so it is better suited for
use in the RPC interface, from whence any application can then make
use of it.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

[Daniel Watts]

Paul Lesniewski wrote:

> On Mon, Jan 26, 2009 at 7:22 AM, Daniel Watts <d@...> wrote:
>> Dear Devs,
>>
>> I am pretty sure a while ago I saw someone who was talking about the
>> squirrelmail imap handling layer in his own application. Presumably
>> because they can then rely on a imap library that is maintained by some
>> mail experts (you!).
>>
>> We're trying to do this ourselves but have found there is a whole bunch
>> of stuff (eg in imap_general.php) that is non-imap - eg calls to
>> creating error boxes and use of global language variables.
>>
>> These require certain other webmail related files to be required which,
>> of course, is added overhead.
>>
>> Do you have available anything/anymethod that doesn't require these
>> extra includes? Or do we just need to go through and strip out anything
>> that isn't directly related to interfacing with imap?
>
> There is not anyone I know of using the IMAP code separately for
> exactly the reason you found.  Doing what you are trying to do is part
> of the work needed to abstract that code so it is better suited for
> use in the RPC interface, from whence any application can then make
> use of it.
>

Ok....so fancy telling us what to do so we can do this and send the file
back?

Guessing two tasks:

1. Make imap*.php files a set of pure imap function files which means
simply stripping out any references to anything else (eg calls to error
box). Functions now just take inputs and return data or error codes.

2. Update all calling files to detect errors themselves (or whatever
else) and act on them.

If it is as simple as that (is it ever?) then we're willing to do part 1.

Let me know.
Daniel




------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

[Paul Lesniewski]

On Thu, Jan 29, 2009 at 3:50 AM, Daniel Watts <d@...> wrote:

> Paul Lesniewski wrote:
>> On Mon, Jan 26, 2009 at 7:22 AM, Daniel Watts <d@...> wrote:
>>> Dear Devs,
>>>
>>> I am pretty sure a while ago I saw someone who was talking about the
>>> squirrelmail imap handling layer in his own application. Presumably
>>> because they can then rely on a imap library that is maintained by some
>>> mail experts (you!).
>>>
>>> We're trying to do this ourselves but have found there is a whole bunch
>>> of stuff (eg in imap_general.php) that is non-imap - eg calls to
>>> creating error boxes and use of global language variables.
>>>
>>> These require certain other webmail related files to be required which,
>>> of course, is added overhead.
>>>
>>> Do you have available anything/anymethod that doesn't require these
>>> extra includes? Or do we just need to go through and strip out anything
>>> that isn't directly related to interfacing with imap?
>>
>> There is not anyone I know of using the IMAP code separately for
>> exactly the reason you found.  Doing what you are trying to do is part
>> of the work needed to abstract that code so it is better suited for
>> use in the RPC interface, from whence any application can then make
>> use of it.
>>
>
> Ok....so fancy telling us what to do so we can do this and send the file
> back?

That's a big conversation.  It's not too easy to quantify here.

> Guessing two tasks:
>
> 1. Make imap*.php files a set of pure imap function files which means
> simply stripping out any references to anything else (eg calls to error
> box). Functions now just take inputs and return data or error codes.

Yes, that's the quickest route to success, however, the ultimate goal
was to refactor all of this into a class structure.

> 2. Update all calling files to detect errors themselves (or whatever
> else) and act on them.

Yep, although again, the ultimate goal included changing how the
backend was accessed from this point as well.

> If it is as simple as that (is it ever?) then we're willing to do part 1.

Even if you limit it to what you have described, it won't be easy -
the IMAP library calls sometimes go several layers deep, so you'll
need to do some of step 2 while doing step 1.  Yeah, it's a mess, but
perhaps the good part is that IF step 1-ish can be achieved, I think
that work would not be lost when we are ready to refactor it all into
a class structure.

 - Paul

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel