home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0096.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  3.5 KB  |  79 lines
  1. >  A design question that other IMAP clients must have dealt
  2. >  with...
  3. >   Many of the bugs in Mailstrom have to do with the expunge process.
  4. >   Every kind of window (reads, replies, browsers, attachments)
  5. >  rely on the IMAP message number, and this changes upon
  6. >  expunge.
  7. >   So there are several approaches...
  8.  
  9.  
  10. >  * always use the MessageID field as the key and lookup IMAP
  11. >  number either from the server or a client index.  [sounds
  12. >  cumbersome, but is the db-esque way to do it]
  13.  
  14.     Won't work, actually. The message-id is only unique from the sender's 
  15. viewpoint. If I send you a message, and also Cc: you in the same message (via a
  16. different mail host) you'll have two messages from me with the same message-id.
  17. How do you determine which one you're getting rid of? (It's also quite likely 
  18. you'll want to keep one and toss the duplicate, making the question even more 
  19. relevant).
  20.     I'm sympathetic. The sequencing really makes disconnected operation 
  21. difficult to shoehorn into the existing protocol.
  22.  
  23. >  * everytime an expunge response comes, propagate a message to
  24. >  all objects telling them to decrement their number if its <
  25. >  the response. [this seems to be what the protocol promotes,
  26. >  but makes an O(n) into O(n^2), and sends a huge number of
  27. >  messages thru out the existing objects on every pass]
  28.  
  29.     Actually, only the server access functions need this number. It can get
  30. outdated on certain objects without penalty. Those objects exist as snapshots 
  31. of what once was. For instance, a "read window" which already has text in it 
  32. can still keep the number it had when it was opened. (It just can't -use- that 
  33. number). Subtle distinction. 
  34.  
  35. >  
  36. >  * assemble all expunge replies, build a temporary message map,
  37. >  and run all windows' references to any message thru a remap
  38. >  function [the current solution, has bugs. Is fixable, but will
  39. >  get even more messy if sorted, filtered views are added]
  40.  
  41.     Isn't this the same mechanism for implementing sort/filter engines?
  42.  
  43. (Maybe you're going about this backwards. Instead of having every object 
  44. maintain its current message number, perhaps the message should just know about
  45. all of its objects...).
  46.  
  47. >  * Only expunge at close. Use filtered views to hide deleted
  48. >  messages, rather than actually expunging.  [this sidesteps the
  49. >  problem, and fits with trash can metaphor, until the user
  50. >  wants to empty trash, which could only be done on
  51. >  disconnection.  This matches my user profile, which is why I rarely
  52. >  see the pbs others report in Mailstrom. ]
  53. >   I'm leaning towards the last of these, but am interested in
  54. >  others' opinions.  Would you as users mind if deleted messages
  55. >  disappeared from the list, and only appeared in a view under
  56. >  the trash can?
  57. >   Adam
  58.  
  59.     You can do this kind of thing with xlview (it's actually my preferred 
  60. mode of running). The complication would be forcing it on folks. When I come in
  61. after a weekend, I sometimes have 20 megs of new mail. I try to get rid of it 
  62. quickly. If I'm forced to disconnect in order to actually get rid of it, it 
  63. makes the MUA less conveneient, IMHO.; and also it is less likely that 
  64. space-conscious sys-admins are going to want to propogate it. Some people NEVER
  65. disconnect, unless something crashes. How do you solve the expunge problem for 
  66. them? 
  67.  
  68. >  
  69. >  -------------------------------------------------- Adam
  70. >  Treister  <treister@forsythe.stanford.edu> Polya Hall 205,
  71. >  Stanford CA 94305 - (415) 725-9449
  72. >  --------------------------------------------------
  73. >
  74.  
  75. mike  
  76.  
  77.  
  78.  
  79.