eCet wrote:
> This is for all develpoers of SM:
>
> I see, that You don't take care of my performance bugreport, and
> feature request. You can't even say that you don't get my emails
> through this list.
>
> I think, that I'm worthy to get a reply for my emails.
>
> What You are doing, is spinele
Marc Groot Koerkamp wrote:
Sorry, we have other priorities.
In the limited time I have next to my daytime job and personal life (which
was almost destroyed due to my busy schedule)I also keep myself busy with
SquirrelMail development. The last month I was working on centralised
initialization cod
Tomas Kuliavas wrote:
Developers might be busy and working on other issues.
If you think that you can enhance SquirrelMail thread sorting code, please
provide patches for 1.5.1 or cvs HEAD version.
I will make the patch right if I will have time for it.
I had this question:
"I think, that it
On Mon, April 10, 2006 09:40, eCet wrote:
>> I agree. What we could do is if the message count in a folder > your
>> supposed 5000 then do FETCH 1:* UID first (which is fast) and then take
>> a slice of that. With the resulting id's we can create a message set and
>> provide the UID search argumen
>> I agree. What we could do is if the message count in a folder > your
>> supposed 5000 then do FETCH 1:* UID first (which is fast) and then take
>> a
>> slice of that. With the resulting id's we can create a message set and
>> provide the UID search argument to the thread call and we are done.
>>
I agree. What we could do is if the message count in a folder > your
supposed 5000 then do FETCH 1:* UID first (which is fast) and then take a
slice of that. With the resulting id's we can create a message set and
provide the UID search argument to the thread call and we are done.
Regards,
Marc
eCet wrote:
I think, that it shoud be a feature request from now on. Is anything
that I can help, or You, the developers take care of everything?
Knock-knock! Is anybody there?
---
This SF.Net email is sponsored by xPML, a groundbreaking s
I agree. What we could do is if the message count in a folder > your
supposed 5000 then do FETCH 1:* UID first (which is fast) and then take a
slice of that. With the resulting id's we can create a message set and
provide the UID search argument to the thread call and we are done.
Regards,
Marc
On Fri, March 24, 2006 09:51, eCet wrote:
> Jonathan Angliss wrote:
>
>
>>
>> Not entirely possible. At least not with accurate results. Plus I
>> think the hold up is in the processing of the THREAD results, and not
>> the fetching of the message headers. The problem you're going to have
>> is
Tomas Kuliavas wrote:
I think yes. So we know the whole number of messages. It is 20.000.
SM don't says SORT (ARRIVAL) ISO-8859-2 ALL, rather It says SORT
(ARRIVAL) ISO-8859-2 2,1,19998,19997..., ...,15000
Nobody cares about the 13422th message. If user wants to access it, ok,
then say to
> Jonathan Angliss wrote:
>
>>
>> Not entirely possible. At least not with accurate results. Plus I
>> think
>> the hold up is in the processing of the THREAD results, and not the
>> fetching of the message headers. The problem you're going to have is
>> you're going to have to fetch the whole t
Jonathan Angliss wrote:
Not entirely possible. At least not with accurate results. Plus I think
the hold up is in the processing of the THREAD results, and not the
fetching of the message headers. The problem you're going to have is
you're going to have to fetch the whole thread response to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, March 23, 2006 13:21, [EMAIL PROTECTED] wrote:
> So I think, I have an idea.
> What if we open a mailbox, get the message count from imap server,
> if it is above a user defined value (e.g. 20.000), then say sort only a
> few of them, (a use
So I think, I have an idea.
What if we open a mailbox, get the message count from imap server,
if it is above a user defined value (e.g. 20.000),
then say sort only a few of them, (a user defined value?) eg 5000,
and query only 5000 headers.
If the user wants to view older messages, then we are q
On Tue, March 21, 2006 20:13, Jonathan Angliss wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On Tue, March 21, 2006 11:13, Marc Groot Koerkamp wrote:
>
>
[..]
>
> [..]
>
>
>>> These IDs then need to be passed onto the code that fetches the
>>> message information. This list of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, March 21, 2006 11:13, Marc Groot Koerkamp wrote:
I agree with this last statement. The backend has a _lot_ to do
with this issue. We use an NFS appliance for a backend that we were
experiencing problems with (high latency) that
On Mon, March 20, 2006 18:02, Jonathan Angliss wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On Mon, March 20, 2006 10:12, eCet wrote:
>
>>> I agree with this last statement. The backend has a _lot_ to do with
>>> this issue. We use an NFS appliance for a backend that we were
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, March 20, 2006 10:12, eCet wrote:
>> I agree with this last statement. The backend has a _lot_ to do with
>> this issue. We use an NFS appliance for a backend that we were
>> experiencing problems with (high latency) that caused the same issue
>> I agree with this last statement. The backend has a _lot_ to do with
>> this issue. We use an NFS appliance for a backend that we were
>> experiencing problems with (high latency) that caused the same issue
>> with large mailboxen.
>
> So if i'm understand right: You are working on this issue?
>
Chris Hilts wrote:
That's easy to do when you're not sorting. Especially if you're not
threading. You can't grab the entire thread without looking for all the
pieces.
It's ok, but I can't say to users, that don't click to sort buttons, or
thread view button.
I suggest you either reduce the
I agree with this last statement. The backend has a _lot_ to do with
this issue. We use an NFS appliance for a backend that we were
experiencing problems with (high latency) that caused the same issue
with large mailboxen.
So if i'm understand right: You are working on this issue?
After correc
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:squirrelmail-
> [EMAIL PROTECTED] On Behalf Of Chris Hilts
> Sent: Monday, March 20, 2006 9:21 AM
> To: eCet
> Cc: squirrelmail-users@lists.sourceforge.net
> Subject: Re: [SM-USERS] Errors on thread view of ove
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
eCet wrote:
> How can that big mailbox handled in SM? I'm not familiar with imap, but
> can that be not to query, and sort all messages at once? Only smaller
> peaces of it (eg5000 messages per slice). Than if user wants to view
> older mails then read
Tomas Kuliavas wrote:
In order to calculate threads imap server must parse all messages and
store thread data until parsing is finished. It takes lots of time and
memory. Enable info plugin in sm 1.5.1 and compare timings of SORT and
THREAD tests.
Yes, THREAD is mutch more slower than SORT.
> So I'we tried with SM1.4.6, but with similar result. The error message
Oh, I'm sorry. Above I'we tried it with SM1.4.5. (I'm tired off now)
The SM1.4.6 is giving another error. With SM1.4.6 the message list is not
appearing, instead the error:
ERROR: Connection dropped by IMAP server.
Query: SO
> On Vas, Március 19, 2006 5:08 pm, Tomas Kuliavas wrote:
>> SquirrelMail threading code depends on IMAP server. Developers tried to
>> optimize php part in 1.5.1. Check if you can reproduce errors in 1.4.6
>> and
>> provide full php version number.
>
> The php verion is:
> PHP 4.4.0 (cli) (built:
On Vas, Március 19, 2006 5:08 pm, Tomas Kuliavas wrote:
> SquirrelMail threading code depends on IMAP server. Developers tried to
> optimize php part in 1.5.1. Check if you can reproduce errors in 1.4.6 and
> provide full php version number.
The php verion is:
PHP 4.4.0 (cli) (built: Sep 4 2005
> Hi All!
>
> I'm in trouble to handle big folders with SM. I'm using SM 1.5.1, courier
> imap, jfs, php 4.4 on slackware. So everithing is woring just fine, but if
> I'm trying to thread sort the folder (with 22k mails) it is giving strange
> errors after 2minute or so. The server side sorting, a
28 matches
Mail list logo
