[Evolution-hackers] any point in server side indices?

2009-09-08 Thread Ross Boylan
Cyrus has a facility to maintain indices on the server.
Will such indices help evolution?  I know it tends to build its own
indices, and so suspect the server side indices are irrelevant (I think
it takes an IMAP SEARCH command to access them).

I'm on evo 2.22 on Debian Lenny.

Thanks.
Ross Boylan

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] More on message state

2007-11-30 Thread Ross Boylan
After poking around, I discovered that although follow up status is
not preserved on copy, and is not kept on the IMAP server even where it
exists, the colored labels are preserved on copy and are kept on the
IMAP server (as $Label1, etc).

So I think I have a solution to my immediate problem:
1) get all messages marked for followup together (e.g., by sorting or
vfolder).
2) select them all
3) right click | label | ToDo.
4) copy the folder.

If I look at the folder from different evo clients, they should all show
the ToDo status (whereas the FollowUp status is kept with the client).

There do seem to more types of message status, and more ways of handling
them internally, then necessary.  I think the situation is this

Replied, seen, and other standard IMAP status information is kept in a
bit mask in a single word and stored in the standard IMAP flags.  These
are copied.

Labels that affect coloring (e.g., To Do) are kept in a special info
structure, and stored on the IMAP server in custom flags $Label1, 2,
etc.  (It might be better to use flags with meaningful names, though
that does increase the risk of clashingn with other uses of those names.
On the other hand, another app that sets a ToDo flag prbably means the
same thing as evolution does).  These are copied.

Mark for followup and its attendent substates--I'm not sure how this
is handled internally, though it may be the string-valued user tags.  It
is not kept on the IMAP server, and is not copied.

Ross
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Is there a reason copy does't preserve mark for followup?

2007-11-29 Thread Ross Boylan
Using evolution 2.10 (but with 1.12 backend) on Debian I notice that
when I copy a folder the flagged as important is preserved but the
mark for followup is not.  I'm guessing most other marks are not
preserved either (though replied is preserved).  The code seems to
show a few state variables are all coded into one binary variable; I'm
guessing these are preserved.  They also seem to be stored on the IMAP
server.

My copies were all on or between IMAP servers, using the IMAP server
type.

Is preserving the other elements of message state (e.g., mark for
followup) simply a missing feature, or is there some reason this doesn't
happen?  In particular, is it missing because it's hard to do?

I'm moving significant amounts of mail between servers; unfortunately, I
didn't notice some of the info was being lost until it was too late.

I'm also poking around to see about saving additional state on the IMAP
server; some folks gave me some pointers earlier.

Thanks.
-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Difficulty of storing flags on IMAP server

2007-10-11 Thread Ross Boylan
I believe that some of the flags associated with messages (e.g.,
follow-up) are stored by the evolution client, rather than kept on the
server.  For at least some IMAP servers it should be possible to define
custom flags on the server and use them.

This would be very useful to me, since I'm accessing the mail from
different locations.  Any idea how big a job this would be to add?  I
might do it, if it's easy.

BTW, is anyone planning on working on the problem that messages flagged
initially flagged as follow-up and later flagged as completed still
show up when you filter by follow-up?

Thanks.
Ross
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Difficulty of storing flags on IMAP server

2007-10-11 Thread Ross Boylan
On Thu, 2007-10-11 at 18:29 +0200, Philip Van Hoof wrote:
 On Thu, 2007-10-11 at 09:18 -0700, Ross Boylan wrote:
  I believe that some of the flags associated with messages (e.g.,
  follow-up) are stored by the evolution client, rather than kept on the
  server.  For at least some IMAP servers it should be possible to define
  custom flags on the server and use them.
  
  This would be very useful to me, since I'm accessing the mail from
  different locations.  Any idea how big a job this would be to add?  I
  might do it, if it's easy.
  
  BTW, is anyone planning on working on the problem that messages flagged
  initially flagged as follow-up and later flagged as completed still
  show up when you filter by follow-up?
  
 
 Search for CAMEL_MESSAGE_INFO_USER_FLAGS and uses of mi-user_flags in
 Camel (better search for -user_flags as that mi part is sometimes
 called info and sometimes with a bunch of casting around it called mi).
 
 In camel-imap-folder.c you can take an example from functions like
 flags_to_label. I guess you'll need to convert your user_flags to custom
 IMAP flags somehow. Not sure how easy that is. 
I guess there's one way to find out:)

I suppose, broadly, that there are 2 approaches.  One would be to mirror
the IMAP flags and the local flags; that would isolate the places that
need to change.  The other would be to integrate the knowledge that the
flags were in the server more fully into the application. It looks as if
some message status information is already obtained from the server
(e.g., flagged as important; seen; replied to) for IMAP, so maybe
extending that wouldn't be too hard.
 
 You can also add new tags (user_tags), which is similar to how
 user_flags work in Camel. It looks like those are already stored
 remotely. I think tags define the colour of the rows in your summary
 view (Important, Personal, Work, etc etc).
 
 You'll have to write ui pieces for this too, in Evolution, of course.
Why do I need to add a ui?  I'm thinking the user experience would be
the same; it all happens behind the scenes.

Thanks for the info.

-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-11 Thread Ross Boylan
I'm preserving the exchange for context; my responses are sprinkled
below.
On Sun, 2007-06-10 at 23:47 -0400, Jeffrey Stedfast wrote:
 On Sun, 2007-06-10 at 15:55 -0700, Ross Boylan wrote:
  On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote:

Second question: even if it creates a folder, does it need to stick
around for the folder creation to finish?  I think I remember seeing
that camel was single-threaded
   
   not true...
 
 I should have been clearer here:
 
 yes, it needs to wait for the folder object instantiation to finish (the
 function returns a pointer to the instantiated object, afterall).
And your proposal with open on that object is designed to decouple
creation of the object from creation of the summary, right?  When I said
folder creation I was thinking of the whole get headers and make index
process.
 
 not true that camel is single-threaded - it has a few of its own threads
 going - most notably is the thread for filtering incoming mail for
 providers like imap and maildir (they share the same thread).
 
   
, relying on the client app to do
threading.  Would there be a way to multi-thread this somewhere
   (either
in camel or in the app)?  Obviously doing so would complicate
   things,
because at some point one might need to block (e.g., if I move a
   message
from folder A to B and then switch the UI to look at B).
   
   okay, I think you need to familiarize yourself with Camel's API before
   we discuss anything further :)
   
  http://www.go-evolution.org/Mail_Threading begins
  The Camel API is blocking and synchronous
  although it then goes on to qualify this:
  Custom Threads
  Two tasks inside Camel use threads internally in order to implement a
  cancellable api ontop of a non-cancellable one.
  
  Further
  Mail-OPS
  mail-ops.h contains asynchronous versions of varous Camel api's
  It sounds as if mail-ops is outside of Camel, however.
 
 it is external to camel, yes.
 
  
  So it sounds as if Camel could (in principle) respond to a move request
  by issuing the appropriate IMAP command and then, starting a thread to
  do the other activities (indexing the target folder and deleting the the
  message from the  source folder) and return.
 
 it could, yes, but it'd need a way to report an error unless it waited
 for the operations to finish before returning. For moving mail, you
 typically want to know that it succeeded :)
 
 all of the current camel APIs are designed such that the caller expects
 that when the function returns, the operation has either succeeded or
 failed (where the failure would be set on the CamelException argument).
 
It would then block on
  operations that attempted to access the target folder until the other
  operations completed.
 
 yes, this is true... well, the way folders are implemented at this time
 anyway...
 
  
  I think this could be called a syncronous API, though perhaps that's a
  stretch.
 
 it is indeed a synchronous API :)
Syncronous, but it fails the you know if you've succeeded when the
function returns test.
 
  
  On the other hand, http://www.go-evolution.org/Camel.Operation does not
  sound like a bocking syncronous API at all, so maybe the statement
  quoted at the top is just obsolete?
 
 Camel code is written under the assumption that it is likely it is being
 used in a thread, so it has CamelOperation as a means to:
 
 1. report the progress
 2. cancel operations (typically i/o)
 
 what happens is Evolution has a thread-pool with a CamelOperation object
 for each of the threads the mailer creates so that it can cancel
 operations and/or get progress updates.
This part of the camel API is not syncronous, right?
 
  
  So, first of all I'm confused about the nature of Camel's API and
  operation as far as threading and syncronicity.  
  
  Second, I don't have a sense of whether its features are historical
  accidents (camel was implemented in a simple way and evo then used it as
  it was)
 
 evolution mailer was originally not multi-threaded if my recollection
 serves correctly, although around the time of the first 0.0 release
 threading was added (about 7 years ago).
 
 camel and evolution were developed together, so their designs evolved
 together.
Why was camel separated out at all?

Side note: when I first was trying to figure out what was going on, I
looked in the evo sources and discovered the code wasn't there, but was
in the evo-data-server.  This was confusing because, at least on debian,
the latter was described as providing calendar and address book
functions.  I think the Debian split mirrors the what I see in your
repository.  My current guess is that some of the code in
evolution-data-server (the directory) is really for evolution, and not
for the evo-data-server application.
 
   or the result of some deliberate design decisions.  Blocking
  syncronous operations are simpler to implement,
 
 yep
 
   to use,
 
 yep
 
   to debug,
 
 yep, altho with threads thrown

Re: [Evolution-hackers] Introduction and Questions

2007-06-11 Thread Ross Boylan
On Mon, 2007-06-11 at 09:46 -0700, Ross Boylan wrote:
 Speaking of complexity, evolution/camel (and maybe Gnome?) do a kind
 of
 objects with C.  Why not just use C++?  Was the C++ toolchain too
 unreliable at the start, or was there some other reason? 
I didn't mean to exclude other alternatives.  The general question was
if you're doing objects anyway, why not use a language that already
supports them?
-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-11 Thread Ross Boylan
On Mon, 2007-06-11 at 14:39 -0400, Jeffrey Stedfast wrote:
So it sounds as if Camel could (in principle) respond to a move
 request
by issuing the appropriate IMAP command and then, starting a
 thread to
do the other activities (indexing the target folder and deleting
 the the
message from the  source folder) and return.
   
   it could, yes, but it'd need a way to report an error unless it
 waited
   for the operations to finish before returning. For moving mail,
 you
   typically want to know that it succeeded :)
   
   all of the current camel APIs are designed such that the caller
 expects
   that when the function returns, the operation has either succeeded
 or
   failed (where the failure would be set on the CamelException
 argument).
   
  It would then block on
operations that attempted to access the target folder until the
 other
operations completed.
   
   yes, this is true... well, the way folders are implemented at this
 time
   anyway...
   

I think this could be called a syncronous API, though perhaps
 that's a
stretch.
   
   it is indeed a synchronous API :)
  Syncronous, but it fails the you know if you've succeeded when the
  function returns test.
 
 most of the camel APIs don't fail that test
 
This was in the context of something I was thinking of (So it sounds as
if Camel could ).  The feature/change I was contemplating sounds as
if it would be a bad idea because it violates the usual model for camel
calls.  Probably either a smaller change (keeping the
blocking/syncronous/useful return values in place) or a bigger one
(general asyncronicity) would be a better idea--at least in a perfect
world of infinite coding time.:)  In fact, your idea with folder open
preserves the expected features of the camel API.
-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-10 Thread Ross Boylan
On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote:
  [Ross wrote]
  Second question: even if it creates a folder, does it need to stick
  around for the folder creation to finish?  I think I remember seeing
  that camel was single-threaded
 
 not true...
 
  , relying on the client app to do
  threading.  Would there be a way to multi-thread this somewhere
 (either
  in camel or in the app)?  Obviously doing so would complicate
 things,
  because at some point one might need to block (e.g., if I move a
 message
  from folder A to B and then switch the UI to look at B).
 
 okay, I think you need to familiarize yourself with Camel's API before
 we discuss anything further :)
 
http://www.go-evolution.org/Mail_Threading begins
The Camel API is blocking and synchronous
although it then goes on to qualify this:
Custom Threads
Two tasks inside Camel use threads internally in order to implement a
cancellable api ontop of a non-cancellable one.

Further
Mail-OPS
mail-ops.h contains asynchronous versions of varous Camel api's
It sounds as if mail-ops is outside of Camel, however.

So it sounds as if Camel could (in principle) respond to a move request
by issuing the appropriate IMAP command and then, starting a thread to
do the other activities (indexing the target folder and deleting the the
message from the  source folder) and return.  It would then block on
operations that attempted to access the target folder until the other
operations completed.

I think this could be called a syncronous API, though perhaps that's a
stretch.

On the other hand, http://www.go-evolution.org/Camel.Operation does not
sound like a bocking syncronous API at all, so maybe the statement
quoted at the top is just obsolete?

So, first of all I'm confused about the nature of Camel's API and
operation as far as threading and syncronicity.  

Second, I don't have a sense of whether its features are historical
accidents (camel was implemented in a simple way and evo then used it as
it was) or the result of some deliberate design decisions.  Blocking
syncronous operations are simpler to implement, to use, to debug, and to
understand, so they clearly have some advantages.   But it seems that
the entire application (evolution) does not have that character, so the
benefits of that simplicity end up lost anyway.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-08 Thread Ross Boylan
On Fri, 2007-06-08 at 17:11 -0400, Jeffrey Stedfast wrote:
 On Fri, 2007-06-08 at 12:23 -0700, Ross Boylan wrote:
  On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote:
   it's not possible to do better w/o dropping features like message
   threading.
   
   In fact, the above minimalizing of header fetching already breaks the
   quick context-menu vfolder on mailing-list and filter on
   mailing-list features as well as making vfoldering on mailing-list
   oodles slower (if it even still works after disabling the headers) 
  What about letting the server do the threading, if it can?
 
 1. not all servers support it, so we need to implement threading
 client-side anyway
 
 2. not all servers do it /correctly/, so we'd need to have a lookup
 table of server idents so we knew when to fallback (note that every mail
 client I know of that tried to be smart and let the server do the
 threading has lived to regret making this decision)
The parenthetical remark is pretty interesting.
 
 3. if threading behavior is different from other accounts, it will feel
 weird to the user.
All good points.  I should explain I'm thinking of a mode that might
kick in only on large mailboxes, or as a user option or something like
that.  My main concern is that with very large folders most mail cients,
including evolution, become sluggish to the point of being unusable.
For many of the clients life is much uglier during the initial contact
with the folders than later.  For example, when I move a message into a
folder I haven't opened or operated on in evolution, I'm noticing long
delays (like  1 minute) while it does something (fetch headers and
create an index?  whatever it is uses some, but not all the CPU).

In this context an responsive but imperfect solution is better than an
unresponsive perfect one.

For example, if evo relies on the server's threads then it will
obviously inherit their behavior, warts and all.  In general I agree
with the point, made recently on this list, that it's desirable for
clients to shield users from server problems (and most users don't know
and don't care that the the real problem is with the server).  But if
doing so takes forever, some may be willing to give up on that.

Whether relaying on server side threading, which currently only operates
on the whole mailbox, can solve the performance problems is another
issue.
 
I realize
  not all can, and probably all will seem not as smart as they could be
  (or just different from how threading would be done in evolution).  But
  otherwise, there's no way around getting lots of headers, and that is a
  huge hit with big folders.
  
  That's the theory; the practice seems uglier.  I tried mulberry, which
  is supposed to make very good use of IMAP.  In many ways it does, but
  its use of server-side threading doesn't work too well.  It seemed to
  get the response back quickly from the server, but then take minutes
  processing and parsing this response.  Furthermore, every time one
  scrolls the window, it does it all over again.
  
  The other problem with server-side threading is that it threads
  everything.  In principle it might make more sense to retrieve a window
  of headers and thread them.
 
 actually, I think this is what Mulberry is doing - or at least that
 would make sense if it has to re-fetch thread info when you scroll.
My impression, based partly on what a (the?) Mulberry developer said, is
that Mulberry gets the entire threaded list from the server.  The time
seems to go into the post-processing, and apparently this gets redone
every time you scroll.  (The developer thought it was time parsing the
response string from the server, though I would think building up a
virtual message list window is a more likely culprit).

BTW, in case people aren't aware, Mulberry was recently open-sourced.
 
  
  The window might not include all items in the thread, but that seems a
  reasonable trade-off to me in return for decent performance.  One could
  do a more thorough job in the background and update when it finished.
 
 but then you have items in the list moving around as more thread info
 becomes available which would be annoying to users, imho.
Worst case the display of the results could be deferred until something
else, like a user hitting a scrollbar, causes a display update.  But I
don't see how this case differs from other things that might change the
display, such as the arrival of new mail.

Ross

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-08 Thread Ross Boylan
On Fri, 2007-06-08 at 18:27 -0400, Jeffrey Stedfast wrote:
 On Fri, 2007-06-08 at 15:13 -0700, Ross Boylan wrote:
  On Fri, 2007-06-08 at 17:11 -0400, Jeffrey Stedfast wrote:
   On Fri, 2007-06-08 at 12:23 -0700, Ross Boylan wrote:
.
  All good points.  I should explain I'm thinking of a mode that might
  kick in only on large mailboxes, or as a user option or something like
  that.  My main concern is that with very large folders most mail cients,
  including evolution, become sluggish to the point of being unusable.
  For many of the clients life is much uglier during the initial contact
  with the folders than later.  For example, when I move a message into a
  folder I haven't opened or operated on in evolution, I'm noticing long
  delays (like  1 minute) while it does something (fetch headers and
  create an index?  whatever it is uses some, but not all the CPU).
 
 yea, it's creating a summary.
 
 IMHO, the design needs to change such that a CamelFolder object need not
 load the summary when instantiated. If that gets implemented, then
 there's no need to hit the server to sync summary info before the object
 gets returned to the caller who requested it, thus allowing appends w/o
 this particular slowness.
 
 This is all part of my camel architecture redesign ideas that I had
 started implementing in libspruce as a testbed. I think Michael Zucchi
 even started to implement this in the disk-summary branch (it basically
 boiled down to ::open() and ::close() methods on a CamelFolder object)
 
Why does it need to create a CamelFolder for the destination at all,
assuming I keep the focus on the source folder?

Actually, I guess I don't know if IMAP copy/delete is happening behind
the scenes, or if camel is creating the message from scratch in the
target folder.  The latter is a lot more work (though probably easier to
implement).

Second question: even if it creates a folder, does it need to stick
around for the folder creation to finish?  I think I remember seeing
that camel was single-threaded, relying on the client app to do
threading.  Would there be a way to multi-thread this somewhere (either
in camel or in the app)?  Obviously doing so would complicate things,
because at some point one might need to block (e.g., if I move a message
from folder A to B and then switch the UI to look at B).

  
  In this context an responsive but imperfect solution is better than an
  unresponsive perfect one.
 
 I would argue that it's not a perfect solution if it's unresponsive :)
For sure.
 
  
  For example, if evo relies on the server's threads then it will
  obviously inherit their behavior, warts and all.  In general I agree
  with the point, made recently on this list, that it's desirable for
  clients to shield users from server problems (and most users don't know
  and don't care that the the real problem is with the server).  But if
  doing so takes forever, some may be willing to give up on that.
  
  Whether relaying on server side threading, which currently only operates
  on the whole mailbox, can solve the performance problems is another
  issue.
 
 it doesn't operate on the whole mailbox, it operates on a seqid or uid
 set afaik.
 
 been a while since I've read the specs
 
I was mistaken about threading being only for the whole box.  I just
looked at
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-18.txt and
see you can add additional search specifications to limit your thread
request.  Of course, clients might still ask for all the threads.

Though I've mostly focused on responsiveness, the index the whole
folder strategy also impacts bandwidth (as Philip pointed out) and
local disk useage.

Ross

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-08 Thread Ross Boylan
On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote:
  Why does it need to create a CamelFolder for the destination at all,
  assuming I keep the focus on the source folder?
 
 because you need both a source and a destination folder to move the
 message(s) to?
 
 kinda hard to move messages to a folder if you don't know which folder
 to move them to, don't you agree? :)
All you need for IMAP is the name of the target folder, not the fuller
representation that CamelFolder provides.  In particular, there's no
need to fetch the headers from the destination folder, index them, etc.

As you observe, I'm not too familiar with camel's internals: just a
quick look at the docs and a little debugging.  So I don't know if such
a minimalist approach would play very well in that framework.

Ross

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-01 Thread Ross Boylan
On Thursday 31 May 2007 16:09, Jeffrey Stedfast wrote:
 On Thu, 2007-05-31 at 17:18 -0400, Jeffrey Stedfast wrote:
 [snip]

   Single namespace.  It's all INBOX.folder.subfolder.
   The one wrinkle is that in some cases 'folder' exists in the namespace,
   but is not an actual box or folder (whatever the right term is) on the
   server: INBOX.folder.subfolder is a real folder; INBOX.folder is not.
 
  I guess just a bug

 I don't have a build environment anymore so I can't easily test this
 patch, but perhaps i will fix your missing folder troubles.

I'm not sure that the names that aren't folders problem is causing any of the 
problems I'm seeing.  While such names don't appear in the folder list on the 
left pane, I also have plenty of ordinary folders that aren't appearing.  And 
the ghost folders, along with their children, do show up in the Folder| 
subscription dialogue.

evolution seems to insist on showing only subscribed folders, even when I 
disable the show only subscribed folders option.

Since the ghost folders aren't folders, there is no way I can subscribe to 
them.  So if I wanted to see only subscribed folders, that might create a 
problem.

I was able to start up evo under the debugger on the system that's having 
problems, and this time it worked.  Yay!

I put future breakpoints on camel_store_supports_subscriptions, and (following 
the location of the patches you provided)  imap4_build_folder_info.  I also 
put one on  imap_build_folder_info (a wild guess).

Unfortunately none of these were hit when evo started up and was deciding what 
to show.  I did hit the camel_store_support_subscriptions when I opened the 
Folders | subscriptions dialogue.

I tried creating an IMAP type account.  This did hit imap_build_folder_info, 
and it did show all my folders (including ghosts).  Performance seems pretty 
good.

I'm going to stop for now, while I'm ahead.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Introduction and Questions

2007-05-31 Thread Ross Boylan
Hi.  I've been getting into the code of evolution recently, and am thinking of 
doing a bit more to see if I can get it working OK for my situation.  I have 
an IMAP mailbox which is very large, both in terms of folders (over 100) and 
messages (the largest folder has 300,000 messages; my INBOX has about 
22,000).

None of the email clients I've tried cope with this very well.  Since I've 
been using evo at work in a similar setup (cyrus server, though not quite as 
big), I thought it might be the best to try to tweak.  The problems I've had 
so far involve setup activities rather than core functionaility.  First, 
evolution couldn't create the account (solved); second I've had problems 
getting it to show all of my subfolders.

My narrow question is how to debug evolution.  When I launched evolution in 
gdb evolution (the GUI) came up, and then the debugger told me the process 
had exited (though the GUI was up and running).  I believe the initial 
process does some kind of activation of the real process and then exits.

I know I can attach to the second process, but I think the stuff I need to see 
happens at startup.  So how can I get a debugger on the startup process of 
the real evolution?

I tried to search the archive, but the search function seems broken: it 
searches everything, even though it says search this list only.

Also, evolution seems to have two presences on the web: a web site and a wiki.  
The developer stuff on the web site is old, and has no pointers to the newer 
stuff that I could find.  It would be good if it did.

I have some broader questions too, if anyone has any comments on them.

What version to start with?  I'm on Debian GNU/Linux, which currently has evo 
2.6.  I notice that's a bit dated (although I did see that a few months ago 
some of the Debian packagers were interested in making a more recent 
version).  I've been working from the Debian version.  Does that version, the 
last stable release (from evo, not Debian), or svn head make the most sense 
to work from?  (BTW, the one bug I fixed was one that was already fixed 
post-2.6).

Mission Impossible?  Am I likely to get anywhere without spending lots of 
time?  I'm a professional software developer, but I'm not familiar with 
GNOME, and this is clearly a complex application.

Mission Advisable?  If I get past the setup hurdles, is evolution likely to be 
able to handle the mail store I described?

How do I find out which of the imap store's code I'm actually using?

Thanks.
Ross Boylan
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-05-31 Thread Ross Boylan
On Thu, 2007-05-31 at 23:14 +0530, Srinivasa Ragavan wrote:
 Hi,
 
 On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote:
  Hi.  I've been getting into the code of evolution recently, and am thinking 
  of 
  doing a bit more to see if I can get it working OK for my situation.  I 
  have 
  an IMAP mailbox which is very large, both in terms of folders (over 100) 
  and 
  messages (the largest folder has 300,000 messages; my INBOX has about 
  22,000).
  
  None of the email clients I've tried cope with this very well.  Since I've 
  been using evo at work in a similar setup (cyrus server, though not quite 
  as 
  big), I thought it might be the best to try to tweak.  The problems I've 
  had 
  so far involve setup activities rather than core functionaility.  First, 
  evolution couldn't create the account (solved); second I've had problems 
  getting it to show all of my subfolders.
  
  My narrow question is how to debug evolution.  When I launched evolution in 
  gdb evolution (the GUI) came up, and then the debugger told me the process 
  had exited (though the GUI was up and running).  I believe the initial 
  process does some kind of activation of the real process and then exits.
 
 Hmm, doesn't it give you a point to do 'bt' to get the traces? 
I don't think there's anything to trace, since the action is happening
in another process.
When I begin I am at the gdb command line.  I was able to insert a
breakpoint at what seemed like a good spot (this was a future
breakpoint, since the relevant library hadn't loaded).  Then when I did
'run' the GUI came up, and the program I was debugging exited.  There
was no error, and I didn't hit the breakpoint, so I don't think bt would
be meaningful.

Or perhaps I'm misunderstanding and it is only one thread that has
exited.  But I see in main.c a lot of IDL code, and I know GNOME apps
are supposed to be able to discover if they've already launched.  I
guessed (mostly by analogy with MS COM) that the initial program simply
requests a service, and that is either conveyed to an existing instance
of the app or a new  instance is created.
 
  
  I know I can attach to the second process, but I think the stuff I need to 
  see 
  happens at startup.  So how can I get a debugger on the startup process of 
  the real evolution?
  

 
-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-05-31 Thread Ross Boylan
On Thu, 2007-05-31 at 14:10 -0400, Jeffrey Stedfast wrote: 
 On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote:
  Hi.  I've been getting into the code of evolution recently, and am thinking 
  of 
  doing a bit more to see if I can get it working OK for my situation.  I 
  have 
  an IMAP mailbox which is very large, both in terms of folders (over 100) 
  and 
  messages (the largest folder has 300,000 messages; my INBOX has about 
  22,000).
 
 the largest INBOX I've ever used was about ~100,000 messages, so you may
 get to have some fun :)
 
  
  None of the email clients I've tried cope with this very well.  Since I've 
  been using evo at work in a similar setup (cyrus server, though not quite 
  as 
  big), I thought it might be the best to try to tweak.  The problems I've 
  had 
  so far involve setup activities rather than core functionaility.  First, 
  evolution couldn't create the account (solved); second I've had problems 
  getting it to show all of my subfolders.
 
 are they in different namespaces? Current evo IMAP provider doesn't
 handle multiple namespaces :(
Single namespace.  It's all INBOX.folder.subfolder.
The one wrinkle is that in some cases 'folder' exists in the namespace,
but is not an actual box or folder (whatever the right term is) on the
server: INBOX.folder.subfolder is a real folder; INBOX.folder is not.
 
  
  My narrow question is how to debug evolution.  When I launched evolution in 
  gdb evolution (the GUI) came up, and then the debugger told me the process 
  had exited (though the GUI was up and running).  I believe the initial 
  process does some kind of activation of the real process and then exits.
 
 sounds like you already had an instance of Evolution running (on another
 virtual desktop perhaps?)
I'm pretty sure I shut everything down.  Hmm, I just tried again and
this time I'm still in the debugger.

There was another instance of evolution running, but for a different
user.  That instance is in a funny state, because it is not visible in
the other user's screen.

Running under KDE in all cases.
 

 
  
  Mission Advisable?  If I get past the setup hurdles, is evolution likely to 
  be 
  able to handle the mail store I described?
 
 I think it'll be possible, there's lots of improvement that can be made
 to the current imap code :)
I'm hoping it will be tolerable without improvements :)  I think one of the 
main factors will be whether evo 
tries to get all the headers from each folder it operates on.  Even if it does, 
if it only does it once
and is otherwise responsive I'll be doing better than what I have now.

At work, I think my biggest folder has about 85k messages, and evo is working 
fine.
 
  
  How do I find out which of the imap store's code I'm actually using?
 
 you are probably using the provider in
 evolution-data-server/camel/providers/imap
Is the other not loaded, or does it depend on which option I picked for the 
server (I said IMAP4rev1).

Thanks to everyone for the quick replies.  Not having a functional email client 
is a big problem. 
I used to archive off my mail when it got to be too much.  I thought it would 
be more convenient to have it
consolidated under IMAP since, as a practical matter, once I archived the stuff 
it became invisible.  So far,
it's not so convenient!

So far, I have tried
evolution
kmail (using it for now)
thunderbird/icedove
mulberry
Apple's mail app
claws
mutt

-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-05-31 Thread Ross Boylan
On Thu, 2007-05-31 at 23:14 +0530, Srinivasa Ragavan wrote:
  [Ross] What version to start with? 
 
 I would prefer, if you can try it with Evolution 2.10.2. It is the
 most recent stable release.
Is EVOLUTION_DATA_SERVER_1_10_2 the corresponding tag to use for
evolution-data-server?
-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-05-31 Thread Ross Boylan
On Thu, 2007-05-31 at 23:20 +0200, Øystein Gisnås wrote:
 2007/5/31, Matthew Barnes [EMAIL PROTECTED]:
  On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote:
   What version to start with?  I'm on Debian GNU/Linux, which currently has 
   evo
   2.6.  I notice that's a bit dated (although I did see that a few months 
   ago
   some of the Debian packagers were interested in making a more recent
   version).  I've been working from the Debian version.  Does that version, 
   the
   last stable release (from evo, not Debian), or svn head make the most 
   sense
   to work from?  (BTW, the one bug I fixed was one that was already fixed
   post-2.6).
 
  FYI, Debian Unstable has Evolution 2.10.  Might be easier to grab at
  least the 2.10 dependencies from there.  You'll need to upgrade gtkhtml
  and likely also your GTK+ library stack to get 2.10 to build.
 
 In case you're on a Debian-based distribution 
Yes; straight Debian.
 and not pulling from
 svn, I would recommend using pre-built packages, or even building the
 packages yourself. 2.10.2 is in the archive, and I will do 2.11.2 this
 weekend.
Terrific.  Is unstable the place to look, or experimental, or somewhere
else?
 
 For my own development setup I use the 2.10.x packages plus custom
 build from svn for the module I'm hacking on. e-d-s for example, I
 install to /opt/evolution-data-server. Then I can start development
 e-d-s with 'LD_LIBRARY_PATH=/opt/evolution-data-server/lib
 /opt/evolution-data-server/libexec/evolution-data-server-1.12' and can
 also start the stable e-d-s with
 '/usr/lib/evolution/evolution-data-server-1.10'
That's a great tip.  I built evo from Debian source (with one fix) and
it took 45 minutes.  I clearly need a shorter route to trying out
changes.

Thanks for packing evo, and for making the -dbg files available.

Ross
-- 
Ross Boylan  wk:  (415) 514-8146
185 Berry St #5700   [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics   fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm:  (415) 550-1062

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers