« Return to Thread: Using Squirrelmail IMAP Core
Re: Using Squirrelmail IMAP Core
by Paul Lesniewski
::
Rate this Message:
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
> 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
« Return to Thread: Using Squirrelmail IMAP Core
| Free embeddable forum powered by Nabble | Forum Help |
