community/pipermail-archives/sup-devel/2010-06.txt (41610B) - raw
1 From sup-bugs@masanjin.net Tue Jun 1 15:28:53 2010
2 From: sup-bugs@masanjin.net (anonymous)
3 Date: Tue, 01 Jun 2010 19:28:53 +0000
4 Subject: [sup-devel] [issue107] all new emails go to inbox
5 In-Reply-To: <1275420532.84.0.199838497104.issue107@masanjin.net>
6 Message-ID: <1275420532.84.0.199838497104.issue107@masanjin.net>
7
8
9 New submission from anonymous:
10
11 after checking out the latest git version, all new emails go to inbox now,
12 although several sources are configured to be archived immediately.
13
14 ----------
15 messages: 242
16 nosy: anonymous
17 priority: bug
18 ruby_version: 1.8.7 (2010-01-10 patchlevel 249)
19 status: unread
20 sup_version: git
21 title: all new emails go to inbox
22
23 _________________________________________
24 Sup issue tracker <sup-bugs at masanjin.net>
25 <http://masanjin.net/sup-bugs/issue107>
26 _________________________________________
27
28 From sup-bugs@masanjin.net Wed Jun 2 18:06:32 2010
29 From: sup-bugs@masanjin.net (Gaute Hope)
30 Date: Wed, 02 Jun 2010 22:06:32 +0000
31 Subject: [sup-devel] [issue108] Feature request: Jump to next message and
32 open in thread-view
33 In-Reply-To: <1275516359-sup-2170@dolk>
34 Message-ID: <1275516359-sup-2170@dolk>
35
36
37 New submission from Gaute Hope <eg at gaute.vetsj.com>:
38
39 The attached patch adds the possibility to jump to the next message and
40 open in one go in thread-view-mode.
41
42 I often want to just skim through a thread; I might have been missing
43 something, but it previously required me to locate the next message hit
44 enter, then repeat..
45
46 Now I can with C-n and C-p jump to the next, have it opened, hit again -
47 it is closed if it was toggled, and continue through the thread.
48
49 Please beware of bad ruby knowledge.
50
51 ----------
52 files: 0001-Jump-and-open-next-previous-message-with-C-n-and-C-p.patch
53 messages: 243
54 nosy: gauteh
55 status: unread
56 title: Feature request: Jump to next message and open in thread-view
57
58 _________________________________________
59 Sup issue tracker <sup-bugs at masanjin.net>
60 <http://masanjin.net/sup-bugs/issue108>
61 _________________________________________
62 -------------- next part --------------
63 A non-text attachment was scrubbed...
64 Name: 0001-Jump-and-open-next-previous-message-with-C-n-and-C-p.patch
65 Type: application/octet-stream
66 Size: 4170 bytes
67 Desc: not available
68 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100602/34b397b2/attachment.obj>
69
70 From sup-bugs@masanjin.net Wed Jun 2 20:18:23 2010
71 From: sup-bugs@masanjin.net (Truxton Fulton)
72 Date: Thu, 03 Jun 2010 00:18:23 +0000
73 Subject: [sup-devel] [issue109] Crash when loading all threads (!!)
74 In-Reply-To: <1275524303.69.0.689658146626.issue109@masanjin.net>
75 Message-ID: <1275524303.69.0.689658146626.issue109@masanjin.net>
76
77
78 New submission from Truxton Fulton <truxton at truxton.com>:
79
80 I started sup
81 There are 127945 messages in index
82 I pressed L then chose a label that had 10122 messages
83 sup displayed the first 60 threads
84 I pressed !! to load all threads
85 (because I want to apply 'a'rchive to all of them)
86 after loading 546 threads, sup crashes (log attached).
87
88 ----------
89 files: exception-log.txt
90 keyword: maildir
91 messages: 244
92 nosy: trux
93 priority: bug
94 ruby_version: 1.8.6
95 status: unread
96 sup_version: 0.11
97 title: Crash when loading all threads (!!)
98
99 _________________________________________
100 Sup issue tracker <sup-bugs at masanjin.net>
101 <http://masanjin.net/sup-bugs/issue109>
102 _________________________________________
103 -------------- next part --------------
104 --- RuntimeError from thread: load threads for thread-index-mode
105 wrong id called on nil
106 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:17:in `id'
107 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:234:in `update'
108 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/hook.rb:123:in `sort_by'
109 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:234:in `each'
110 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:234:in `sort_by'
111 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:234:in `update'
112 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:232:in `synchronize'
113 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:232:in `update'
114 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:643:in `__unprotected_load_n_threads'
115 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/thread.rb:334:in `load_n_threads'
116 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:148:in `each_id_by_date'
117 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:239:in `each_id'
118 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:239:in `each'
119 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:239:in `each_id'
120 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:148:in `each_id_by_date'
121 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/thread.rb:328:in `load_n_threads'
122 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:640:in `__unprotected_load_n_threads'
123 (eval):12:in `load_n_threads'
124 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:624:in `load_n_threads_background'
125 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:76:in `reporting_thread'
126 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:74:in `initialize'
127 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:74:in `new'
128 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:74:in `reporting_thread'
129 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:623:in `load_n_threads_background'
130 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:694:in `__unprotected_load_threads'
131 (eval):12:in `load_threads'
132 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:673:in `load_all_threads'
133 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/mode.rb:59:in `send'
134 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/mode.rb:59:in `handle_input'
135 /usr/lib/ruby/gems/1.8/gems/sup-0.11/lib/sup/buffer.rb:279:in `handle_input'
136 /usr/lib/ruby/gems/1.8/gems/sup-0.11/bin/sup:279
137 /usr/bin/sup:19:in `load'
138 /usr/bin/sup:19
139
140 From rlane@club.cc.cmu.edu Wed Jun 2 23:57:41 2010
141 From: rlane@club.cc.cmu.edu (Rich Lane)
142 Date: Wed, 02 Jun 2010 23:57:41 -0400
143 Subject: [sup-devel] [issue108] Feature request: Jump to next message
144 and open in thread-view
145 In-Reply-To: <1275516359-sup-2170@dolk>
146 References: <1275516359-sup-2170@dolk>
147 Message-ID: <1275537191-sup-9518@zyrg.net>
148
149 Excerpts from Gaute Hope's message of 2010-06-02 18:06:32 -0400:
150 >
151 > New submission from Gaute Hope <eg at gaute.vetsj.com>:
152 >
153 > The attached patch adds the possibility to jump to the next message and
154 > open in one go in thread-view-mode.
155 >
156 > I often want to just skim through a thread; I might have been missing
157 > something, but it previously required me to locate the next message hit
158 > enter, then repeat..
159 >
160 > Now I can with C-n and C-p jump to the next, have it opened, hit again -
161 > it is closed if it was toggled, and continue through the thread.
162 >
163 > Please beware of bad ruby knowledge.
164
165 Applied to master.
166
167 From rlane@club.cc.cmu.edu Wed Jun 2 23:58:20 2010
168 From: rlane@club.cc.cmu.edu (Rich Lane)
169 Date: Wed, 02 Jun 2010 23:58:20 -0400
170 Subject: [sup-devel] [PATCH] Respect source.archived? in poll.
171 In-Reply-To: <1274910492-13206-1-git-send-email-pi+sup@pihost.us>
172 References: <1274910492-13206-1-git-send-email-pi+sup@pihost.us>
173 Message-ID: <1275537478-sup-8837@zyrg.net>
174
175 Applied to master.
176
177 From rlane@club.cc.cmu.edu Wed Jun 2 23:58:49 2010
178 From: rlane@club.cc.cmu.edu (Rich Lane)
179 Date: Wed, 02 Jun 2010 23:58:49 -0400
180 Subject: [sup-devel] [PATCH] Allow toggle on Source.usual and
181 Source.archived
182 In-Reply-To: <1273949121-16731-1-git-send-email-bwalton@artsci.utoronto.ca>
183 References: <1273949121-16731-1-git-send-email-bwalton@artsci.utoronto.ca>
184 Message-ID: <1275537512-sup-176@zyrg.net>
185
186 Applied to master.
187
188 From rlane@club.cc.cmu.edu Thu Jun 3 00:27:04 2010
189 From: rlane@club.cc.cmu.edu (Rich Lane)
190 Date: Thu, 03 Jun 2010 00:27:04 -0400
191 Subject: [sup-devel] email threading - tree vs. graph
192 In-Reply-To: <20100525185026.GA11947@thialfi.home.net>
193 References: <20100218114943.GB911@mjolnir> <1266730498-sup-78@tilus.net>
194 <20100525185026.GA11947@thialfi.home.net>
195 Message-ID: <1275538158-sup-1305@zyrg.net>
196
197 Excerpts from W. Trevor King's message of 2010-05-25 14:50:27 -0400:
198 > I got some good feedback from Nicolas Pouillard on the Python tidbit I
199 > posted, but after waiting optimisticly for some enterprising Rubist to
200 > port it to Ruby and merge it into Sup, I've finally taught myself
201 > enough Ruby to do it myself ;). Here's DAG-supporting Sup (+ a few
202 > glaring documentation updates)
203
204 Thanks for the doc updates, I've applied them to master.
205
206 I'm not yet convinced that supporting multiple parents is worth
207 the complexity. How often do you get mails like this? What mail clients
208 have UI for replying to multiple messages? I'd have to fake up some
209 messages to actually see the full DAG support in action, so could you
210 post a screenshot of your code viewing a thread where the new display
211 helps?
212
213 > We could also resurect the old indentation-style display in the thread
214 > viewer, if people dislike my tig-style ascii graph.
215
216 Actually, I think the tig-style display is very interesting and could be
217 useful even without the generic graph support.
218
219 From truxton@truxton.com Thu Jun 3 04:27:34 2010
220 From: truxton@truxton.com (Truxton Fulton)
221 Date: Thu, 03 Jun 2010 01:27:34 -0700
222 Subject: [sup-devel] [issue109] Crash when loading all threads (!!)
223 In-Reply-To: <1275524303.69.0.689658146626.issue109@masanjin.net>
224 References: <1275524303.69.0.689658146626.issue109@masanjin.net>
225 Message-ID: <1275553467-sup-5430@terrapin.truxton.com>
226
227 Hi sup developers!
228
229 I've narrowed down the crash to the presence of 2 particular mails.
230 I can reproduce the crash by creating a brand new sup config
231 for a maildir containing only these 2 messages. When sup starts
232 up it gets the "wrong id called on nil" crash. It seems that
233 either message by itself is fine, but the combination of the
234 two messages causes the problem.
235
236 You can download these mails from my web server :
237
238 http://www.truxton.com/bad2.tar.gz
239
240 Thanks,
241
242 -Truxton
243 --
244
245 From wking@drexel.edu Thu Jun 3 06:21:10 2010
246 From: wking@drexel.edu (W. Trevor King)
247 Date: Thu, 3 Jun 2010 06:21:10 -0400
248 Subject: [sup-devel] email threading - tree vs. graph
249 In-Reply-To: <1275538158-sup-1305@zyrg.net>
250 References: <20100218114943.GB911@mjolnir> <1266730498-sup-78@tilus.net>
251 <20100525185026.GA11947@thialfi.home.net>
252 <1275538158-sup-1305@zyrg.net>
253 Message-ID: <20100603102109.GA1499@thialfi>
254
255 On Thu, Jun 03, 2010 at 12:27:04AM -0400, Rich Lane wrote:
256 > I'm not yet convinced that supporting multiple parents is worth
257 > the complexity. How often do you get mails like this?
258
259 I don't get mails with multiple in-reply-tos, but I send them ;). I
260 *do* get mails with in-text references to multiple messages. For some
261 mailing lists that I care about (be-devel), I go through and adjust
262 in-reply-to so that it matches the in-text references.
263
264 I think such graphs would be a nice interface to mailing lists, which
265 gain members not familiar with the lists history. Browsing a curated
266 list, finding the critical background for a particular message would
267 be trivial.
268
269 > What mail clients have UI for replying to multiple messages?
270
271 In Mutt, you can tag a bunch of messages, and then ;g to reply-to-all
272 the tagged messages at once. I started doing this to get the previous
273 text from all the messages included in my reply, so I expect this sort
274 of thing does occur occasionally in the wild.
275
276 > I'd have to fake up some messages to actually see the full DAG
277 > support in action, so could you post a screenshot of your code
278 > viewing a thread where the new display helps?
279
280 Attached is a small graph showing two related threads about
281 bzr+windows. The multiparent replies allow responses like Matt's,
282 "we discussed this last year" message.
283
284 --
285 This email may be signed or encrypted with GPG (http://www.gnupg.org).
286 The GPG signature (if present) will be attached as 'signature.asc'.
287 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
288
289 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
290 -------------- next part --------------
291 A non-text attachment was scrubbed...
292 Name: graph-threading.png
293 Type: image/png
294 Size: 13150 bytes
295 Desc: not available
296 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100603/595e2c32/attachment-0001.png>
297 -------------- next part --------------
298 A non-text attachment was scrubbed...
299 Name: not available
300 Type: application/pgp-signature
301 Size: 198 bytes
302 Desc: not available
303 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100603/595e2c32/attachment-0001.bin>
304
305 From michael+sup@stapelberg.de Fri Jun 4 05:59:53 2010
306 From: michael+sup@stapelberg.de (Michael Stapelberg)
307 Date: Fri, 04 Jun 2010 11:59:53 +0200
308 Subject: [sup-devel] [PATCH] Bugfix: Charset conversion needs to take place
309 *after* verifying inline GPG signatures
310 Message-ID: <1275645515-sup-4706@midna.zekjur.net>
311
312 Hi,
313
314 still fixing some inline GPG problems ;-). This one is a little subtle: If the
315 message arrives in a different encoding than UTF-8 (shame on the sender), the
316 verification will fail because sup modifies the message by converting it to
317 UTF-8. The attached patch fixes this.
318
319 Best regards,
320 Michael
321 -------------- next part --------------
322 A non-text attachment was scrubbed...
323 Name: 0001-Bugfix-Charset-conversion-needs-to-take-place-after-.patch
324 Type: application/octet-stream
325 Size: 2799 bytes
326 Desc: not available
327 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100604/3c41f615/attachment.obj>
328
329 From sean@silentflame.com Fri Jun 4 09:44:04 2010
330 From: sean@silentflame.com (Sean Whitton)
331 Date: Fri, 4 Jun 2010 14:44:04 +0100
332 Subject: [sup-devel] Storing message tags and other Sup info as headers in
333 Maildir
334 Message-ID: <20100604134404.GA28767@artemis.silentflame.com>
335
336 Dear all,
337
338 I've been checking back to the Sup website every few months for the past
339 year or so, waiting until Sup starts to look more stable and suitable
340 for regular use. Like many people on this list, a great stumbling block
341 to adoption is the fact that Sup doesn't really let you access your
342 e-mail with anything other than Sup. At the moment I use offlineimap
343 and read my mail with Mutt, but my phone and SquirrelMail can access the
344 Maildir just as well (by IMAP in the former case), and so everything
345 stays in sync and I can get to my e-mail from many places.
346
347 Now, I am no real coder, and I've never written a line of ruby, but a
348 thought has occurred to me that I feel I should at least share, even if
349 it turns out to be completely impractical. Why not store the
350 information associated with e-mails that is not rebuildable (that is,
351 tags, unread/read status, starred status, archived/killed/spam status)
352 as header lines (X-Sup-Tags: X-Sup-Status, and I guess read/unread could
353 be standard Maildir flags) in the e-mails themselves in the Maildir?
354
355 This way, the Sup index could be rebuilt on multiple client machines
356 without any data actually going out of sync. You'll still have a
357 punishing index rebuild every time you view your mail on a new machine,
358 but they'll never be the problem of things actually being wrong - tags
359 and stars and the like can all be propagated by offlineimap/IMAP. The
360 indexer can rip out these flags into its index to maintain Sup's
361 professed speed, and then if they change, write them back into the
362 Maildir along with read/unread status and other flags.
363
364 Does this exposition make sense? Is this a practical way to
365 improve/create Sup's multi-client support?
366
367 S
368
369 --
370 Sean Whitton / <sean at silentflame.com>
371 OpenPGP KeyID: 0x3B6D411B
372 http://seanwhitton.com/
373
374 -------------- next part --------------
375 A non-text attachment was scrubbed...
376 Name: not available
377 Type: application/pgp-signature
378 Size: 836 bytes
379 Desc: Digital signature
380 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100604/d85f5e9b/attachment.bin>
381
382 From michael+sup@stapelberg.de Fri Jun 4 18:17:54 2010
383 From: michael+sup@stapelberg.de (Michael Stapelberg)
384 Date: Sat, 05 Jun 2010 00:17:54 +0200
385 Subject: [sup-devel] [PATCH] Decode messages according to their
386 Content-Transfer-Encoding
387 Message-ID: <1275689764-sup-3384@midna.zekjur.net>
388
389 Hi,
390
391 quote of the commit message:
392 Decode messages according to their Content-Transfer-Encoding
393
394 This is necessary for MIME-messages (for example as part of multipart/signed)
395 which are encoded in base64.
396
397 Best regards,
398 Michael
399 -------------- next part --------------
400 A non-text attachment was scrubbed...
401 Name: 0001-Decode-messages-according-to-their-Content-Transfer-.patch
402 Type: application/octet-stream
403 Size: 1433 bytes
404 Desc: not available
405 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100605/b307d5aa/attachment.obj>
406
407 From rlane@club.cc.cmu.edu Fri Jun 4 22:54:24 2010
408 From: rlane@club.cc.cmu.edu (Rich Lane)
409 Date: Fri, 04 Jun 2010 22:54:24 -0400
410 Subject: [sup-devel] [PATCH] Decode messages according to their
411 Content-Transfer-Encoding
412 In-Reply-To: <1275689764-sup-3384@midna.zekjur.net>
413 References: <1275689764-sup-3384@midna.zekjur.net>
414 Message-ID: <1275706048-sup-6981@zyrg.net>
415
416 Excerpts from Michael Stapelberg's message of 2010-06-04 18:17:54 -0400:
417 > Decode messages according to their Content-Transfer-Encoding
418 >
419 > This is necessary for MIME-messages (for example as part of multipart/signed)
420 > which are encoded in base64.
421
422 Do we need to do this in other places too?
423
424 From rlane@club.cc.cmu.edu Fri Jun 4 22:55:08 2010
425 From: rlane@club.cc.cmu.edu (Rich Lane)
426 Date: Fri, 04 Jun 2010 22:55:08 -0400
427 Subject: [sup-devel] [PATCH] Bugfix: Charset conversion needs to take
428 place *after* verifying inline GPG signatures
429 In-Reply-To: <1275645515-sup-4706@midna.zekjur.net>
430 References: <1275645515-sup-4706@midna.zekjur.net>
431 Message-ID: <1275706494-sup-497@zyrg.net>
432
433 Applied to master.
434
435 From michael+sup@stapelberg.de Sat Jun 5 06:55:39 2010
436 From: michael+sup@stapelberg.de (Michael Stapelberg)
437 Date: Sat, 05 Jun 2010 12:55:39 +0200
438 Subject: [sup-devel] [PATCH] Decode messages according to their
439 Content-Transfer-Encoding
440 In-Reply-To: <1275706048-sup-6981@zyrg.net>
441 References: <1275689764-sup-3384@midna.zekjur.net>
442 <1275706048-sup-6981@zyrg.net>
443 Message-ID: <1275735302-sup-799@midna.zekjur.net>
444
445 Hi Rich,
446
447 Excerpts from Rich Lane's message of 2010-06-05 04:54:24 +0200:
448 > Do we need to do this in other places too?
449 Not sure, unfortunately. I?d guess only for MIME messages, for other
450 messages the Transfer-Encoding seems to work already.
451
452 Best regards,
453 Michael
454
455 From rlane@club.cc.cmu.edu Mon Jun 7 11:55:59 2010
456 From: rlane@club.cc.cmu.edu (Rich Lane)
457 Date: Mon, 07 Jun 2010 11:55:59 -0400
458 Subject: [sup-devel] [PATCH] Decode messages according to their
459 Content-Transfer-Encoding
460 In-Reply-To: <1275735302-sup-799@midna.zekjur.net>
461 References: <1275689764-sup-3384@midna.zekjur.net>
462 <1275706048-sup-6981@zyrg.net>
463 <1275735302-sup-799@midna.zekjur.net>
464 Message-ID: <1275926137-sup-8653@zyrg.net>
465
466 Excerpts from Michael Stapelberg's message of 2010-06-05 06:55:39 -0400:
467 > Excerpts from Rich Lane's message of 2010-06-05 04:54:24 +0200:
468 > > Do we need to do this in other places too?
469 > Not sure, unfortunately. I?d guess only for MIME messages, for other
470 > messages the Transfer-Encoding seems to work already.
471
472 Ok, applied to master.
473
474 From snaipperi@gmail.com Mon Jun 7 23:14:08 2010
475 From: snaipperi@gmail.com (Matti Eiden)
476 Date: Tue, 8 Jun 2010 06:14:08 +0300
477 Subject: [sup-devel] Storing message tags and other Sup info as headers
478 in Maildir
479 In-Reply-To: <20100604134404.GA28767@artemis.silentflame.com>
480 References: <20100604134404.GA28767@artemis.silentflame.com>
481 Message-ID: <AANLkTikI63bB_jx3EJsJ15iObHWLZJf_x0d8iw-gDrXP@mail.gmail.com>
482
483 Hi Sean,
484
485 I was expecting somebody else to reply in this but since I'm not
486 seeing anyone doing so, I'll give it a shot. I only recently
487 discovered sup, and I'm not a Ruby programmer, however I got quite a
488 bunch of experience with Python (now the rest of the mailing list can
489 proceed flaming me). The following post is purely speculative.
490
491 Shortly put, I don't expect to see any change on this matter, at least
492 in the near future. There is and has been a tool, sup-sync-back which
493 should reflect the changes back to mbox/maildir but the way it works
494 is far from ideal, I guess. Anyway..
495
496 Let's get one thing straight first, sup doesn't really use specific
497 status flags/tags or such for mails. Instead, every piece of
498 information is in the labels. A couple of labels are predefined:
499 Attachment, Deleted, Draft, Inbox, Killed, Sent, Spam, Starred and
500 Unread. Technically, a message that is archived is simply lacking the
501 label "Inbox". Rest of the labels are user-defined.
502
503 Standard maildir format already provides following flags by default:
504 (S)een, (T)rashed, (D)raft. In addition flags that sup doesn't need;
505 Passed, Replied and Flagged.
506
507 Dovecot (an IMAP server) provides user defined flags for maildirs. The
508 flags are lowercase letters ranging a-z (up to 26 different), and
509 seems like it works OK with the maildir. (
510 http://wiki.dovecot.org/MailboxFormat/Maildir ). This could be one
511 nice option if a limit of some 20 user tags aren't too few.
512
513 Example maildir mail flags:
514 :2,Sacd
515
516 S - standard maildir flag: Seen, MUA would label as "Read"
517 a - custom flag - MUA would label as "Archived"
518 b - custom flag - MUA would label as "Starred"
519 d - custom flag - User would label as "Work"
520
521 This is of course kinda opposite to sup's current situation where
522 messages are defined as Unread or Inbox, but anyway..
523
524
525 Personally I don't like the idea of MUA messing up with the email
526 headers as you suggested. Plus, this would result in a lot of
527 fragmentation on a hard disk with tens of thousands of emails, if on
528 initial sync sup would need to write label information in the middle
529 of every email. And as always when writing, there's a risk of data
530 loss, which would require additional measures.
531
532 This area interests me, however, and I guess I'm gonna make some
533 experiments how the flagging thing works in action, and if it makes
534 other mail clients break. (I doubt it does, otherwise Dovecot wouldn't
535 be using it, huh?).
536
537 Regards,
538 Matti
539
540 From damien.leone@fensalir.fr Wed Jun 9 08:53:16 2010
541 From: damien.leone@fensalir.fr (Damien Leone)
542 Date: Wed, 09 Jun 2010 14:53:16 +0200
543 Subject: [sup-devel] [PATCHES] reply-mode, signatures and account selector
544 Message-ID: <1276087951-sup-7816@mailer>
545
546 Sup guys,
547
548 Three patches are attached to this email, the commit messages should
549 be self explanatory but here are some more details:
550
551 As the first patch changes the way headers are handled in reply-mode
552 there is a regression in the before-edit hook possibilities.
553 Before, we could write something like:
554
555 if header["Cc"] == "foo"
556 header["Bcc"] = "bar"
557 end
558
559 Hence, switching the reply-to type using the selector would have
560 changed the Bcc field if a type using Cc was selected.
561
562 This would be no longer possible since there is now only one "set" of
563 headers running the hook, however if you properly wrote your reply-to
564 hook you can select the reply type you want and the previous code
565 will be working as expected.
566
567 On the other hand (in my opinion), the reply-mode now handles better
568 its job, that is to say changing To and Cc without interfering with
569 other fields that might have been edited manually by the user.
570
571 I asked rlane about this on IRC:
572 > <dleone> what is the reason for the before-edit hook being runned on @bodies and @header for each Reply-To types?
573 > <rlane> that's so that when you switch reply-to type the right signature/etc is displayed
574
575 I see no regression regarding this in the patch, so it should be okay.
576
577 Other patches add an account selector in edit-mode (it is useful to me
578 and I saw requests for such a feature) and a better signature handling
579 regarding the edit_signature option.
580
581 Regards,
582 -------------- next part --------------
583 A non-text attachment was scrubbed...
584 Name: 0001-reply-mode-improve-the-way-headers-are-handled.patch
585 Type: application/octet-stream
586 Size: 5335 bytes
587 Desc: not available
588 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100609/e3f92192/attachment-0003.obj>
589 -------------- next part --------------
590 A non-text attachment was scrubbed...
591 Name: 0002-Add-account_selector-config-option.patch
592 Type: application/octet-stream
593 Size: 3643 bytes
594 Desc: not available
595 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100609/e3f92192/attachment-0004.obj>
596 -------------- next part --------------
597 A non-text attachment was scrubbed...
598 Name: 0003-edit-mode-change-the-way-signatures-are-handled.patch
599 Type: application/octet-stream
600 Size: 2855 bytes
601 Desc: not available
602 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100609/e3f92192/attachment-0005.obj>
603
604 From damien.leone@fensalir.fr Wed Jun 9 09:15:11 2010
605 From: damien.leone@fensalir.fr (Damien Leone)
606 Date: Wed, 09 Jun 2010 15:15:11 +0200
607 Subject: [sup-devel] [PATCHES] reply-mode,
608 signatures and account selector
609 In-Reply-To: <1276087951-sup-7816@mailer>
610 References: <1276087951-sup-7816@mailer>
611 Message-ID: <1276089233-sup-510@mailer>
612
613 I noticed an error in the third patch.
614 Please consider the one attached to *this* email.
615
616 Regards,
617
618 Excerpts from Damien Leone's message of mer. juin 09 14:53:16 +0200 2010:
619 > Sup guys,
620 >
621 > Three patches are attached to this email, the commit messages should
622 > be self explanatory but here are some more details:
623 >
624 > As the first patch changes the way headers are handled in reply-mode
625 > there is a regression in the before-edit hook possibilities.
626 > Before, we could write something like:
627 >
628 > if header["Cc"] == "foo"
629 > header["Bcc"] = "bar"
630 > end
631 >
632 > Hence, switching the reply-to type using the selector would have
633 > changed the Bcc field if a type using Cc was selected.
634 >
635 > This would be no longer possible since there is now only one "set" of
636 > headers running the hook, however if you properly wrote your reply-to
637 > hook you can select the reply type you want and the previous code
638 > will be working as expected.
639 >
640 > On the other hand (in my opinion), the reply-mode now handles better
641 > its job, that is to say changing To and Cc without interfering with
642 > other fields that might have been edited manually by the user.
643 >
644 > I asked rlane about this on IRC:
645 > > <dleone> what is the reason for the before-edit hook being runned on @bodies and @header for each Reply-To types?
646 > > <rlane> that's so that when you switch reply-to type the right signature/etc is displayed
647 >
648 > I see no regression regarding this in the patch, so it should be okay.
649 >
650 > Other patches add an account selector in edit-mode (it is useful to me
651 > and I saw requests for such a feature) and a better signature handling
652 > regarding the edit_signature option.
653 >
654 > Regards,
655
656 --
657 Damien Leone <damien.leone at fensalir.fr>
658
659 Web: http://dleone.fensalir.fr/
660 GPG: 0x82EB4DDF
661 -------------- next part --------------
662 A non-text attachment was scrubbed...
663 Name: 0003-edit-mode-change-the-way-signatures-are-handled.patch
664 Type: application/octet-stream
665 Size: 3257 bytes
666 Desc: not available
667 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100609/aca1d795/attachment.obj>
668
669 From sean@silentflame.com Wed Jun 9 13:42:08 2010
670 From: sean@silentflame.com (Sean Whitton)
671 Date: Wed, 9 Jun 2010 18:42:08 +0100
672 Subject: [sup-devel] Storing message tags and other Sup info as headers
673 in Maildir
674 In-Reply-To: <AANLkTikI63bB_jx3EJsJ15iObHWLZJf_x0d8iw-gDrXP@mail.gmail.com>
675 References: <20100604134404.GA28767@artemis.silentflame.com>
676 <AANLkTikI63bB_jx3EJsJ15iObHWLZJf_x0d8iw-gDrXP@mail.gmail.com>
677 Message-ID: <20100609174207.GA22445@artemis.silentflame.com>
678
679 Hi Matti,
680
681 Thanks for the informative reply. IMAP user-defined flags sound like an
682 excellent way to go about this, but of course, not everyone uses dovecot
683 (dunno why!). Let me know how you get on.
684
685 On Tue, Jun 08, 2010 at 06:14:08AM +0300, Matti Eiden wrote:
686 > I was expecting somebody else to reply in this but since I'm not
687 > seeing anyone doing so, I'll give it a shot. I only recently
688 > discovered sup, and I'm not a Ruby programmer, however I got quite a
689 > bunch of experience with Python (now the rest of the mailing list can
690 > proceed flaming me). The following post is purely speculative.
691 >
692 > Shortly put, I don't expect to see any change on this matter, at least
693 > in the near future. There is and has been a tool, sup-sync-back which
694 > should reflect the changes back to mbox/maildir but the way it works
695 > is far from ideal, I guess. Anyway..
696
697 I keep hearing about sup-sync-back but I'm not sure really what it does.
698 Where can I find information about it?
699
700 S
701
702 --
703 Sean Whitton / <sean at silentflame.com>
704 OpenPGP KeyID: 0x3B6D411B
705 http://seanwhitton.com/
706
707 -------------- next part --------------
708 A non-text attachment was scrubbed...
709 Name: not available
710 Type: application/pgp-signature
711 Size: 836 bytes
712 Desc: Digital signature
713 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100609/8fdaecac/attachment.bin>
714
715 From gregor@hoffleit.de Thu Jun 10 09:05:07 2010
716 From: gregor@hoffleit.de (Gregor Hoffleit)
717 Date: Thu, 10 Jun 2010 15:05:07 +0200
718 Subject: [sup-devel] Bug with searching for multiple labels at once
719 In-Reply-To: <1276171687-sup-6993@sam.mediasupervision.de>
720 References: <1276098490-sup-8738@sam.mediasupervision.de>
721 <1276170636-sup-6551@r61>
722 <1276171687-sup-6993@sam.mediasupervision.de>
723 Message-ID: <1276175002-sup-9199@sam.mediasupervision.de>
724
725 Indeed, I just noticed that the NewUserGuide.txt is much more up-to-date
726 than the Wiki (http://sup.rubyforge.org/wiki/wiki.pl?SearchingMail).
727
728 As a start, I copied the information from the NewUserGuide to that Wiki
729 page. Still, somebody who knows better should update that page.
730 Furthermore, I marked the information in "Testing Xapian" as obsolete in
731 the Wiki.
732
733
734 Still, it is not clear to me what happens without explicit AND or OR
735 operator.
736
737 "label:somelabel label:anotherlabel" seems to be equivalent to
738 "label:somelabel OR label:anotherlabel".
739
740 "label:ruby-talk subject:\[ANN\]" seem to be equivalent to
741 "label:ruby-talk AND subject:\[ANN\]".
742
743 The Xapian QueryParser documentation (http://xapian.org/docs/queryparser.html)
744 is not clear about this either.
745
746
747 Regards,
748 Gregor Hoffleit
749
750 From sup-bugs@masanjin.net Sun Jun 13 03:11:19 2010
751 From: sup-bugs@masanjin.net (anonymous)
752 Date: Sun, 13 Jun 2010 07:11:19 +0000
753 Subject: [sup-devel] [issue110] RuntimeError from thread: load threads
754 for thread-index-mode
755 In-Reply-To: <1276413079.42.0.0334970771348.issue110@masanjin.net>
756 Message-ID: <1276413079.42.0.0334970771348.issue110@masanjin.net>
757
758
759 New submission from anonymous:
760
761 The first time I tried sup, with no mail in maildir, it opened without any problem.
762 When I tried to open sup after fetchmail and procmail, with a few hundred
763 messages, it crashed while it was opening, as shown in the attachment.
764
765 ----------
766 files: exception-log.txt
767 messages: 252
768 nosy: anonymous
769 priority: bug
770 ruby_version: ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]
771 status: unread
772 sup_version: v0.11
773 title: RuntimeError from thread: load threads for thread-index-mode
774
775 _________________________________________
776 Sup issue tracker <sup-bugs at masanjin.net>
777 <http://masanjin.net/sup-bugs/issue110>
778 _________________________________________
779 -------------- next part --------------
780 --- RuntimeError from thread: load threads for thread-index-mode
781 invalid source 2
782 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:197:in `build_message'
783 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:148:in `each_id_by_date'
784 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/thread.rb:332:in `call'
785 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/thread.rb:332:in `load_n_threads'
786 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:148:in `each_id_by_date'
787 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:239:in `each_id'
788 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:239:in `each'
789 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:239:in `each_id'
790 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/index.rb:148:in `each_id_by_date'
791 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/thread.rb:328:in `load_n_threads'
792 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:640:in `__unprotected_load_n_threads'
793 (eval):12:in `load_n_threads'
794 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:624:in `load_n_threads_background'
795 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:76:in `reporting_thread'
796 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:74:in `initialize'
797 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:74:in `new'
798 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup.rb:74:in `reporting_thread'
799 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:623:in `load_n_threads_background'
800 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/lib/sup/modes/thread-index-mode.rb:694:in `__unprotected_load_threads'
801 (eval):12:in `load_threads'
802 /usr/lib64/ruby/gems/1.8/gems/sup-0.11/bin/sup:231
803 /usr/bin/sup:19:in `load'
804 /usr/bin/sup:19
805
806 From michael+sup@stapelberg.de Wed Jun 16 14:11:47 2010
807 From: michael+sup@stapelberg.de (Michael Stapelberg)
808 Date: Wed, 16 Jun 2010 20:11:47 +0200
809 Subject: [sup-devel] =?utf-8?b?W1BBVENIXSBEb27igJl0IGRpc3BsYXkgIi4uLiIg?=
810 =?utf-8?q?after_snippets_which_are_displayed_completely?=
811 Message-ID: <1276711781-sup-4102@midna.zekjur.net>
812
813 Hi,
814
815 quote from the commit message:
816 Don?t display "..." after snippets which are displayed completely
817
818 Short mails (for example: "Yes, the date works for me.") often can
819 be displayed completely in the snippet. However, before this patch,
820 sup abbreviated the snippet even though it was not abbreviated.
821
822
823 Best regards,
824 Michael
825 -------------- next part --------------
826 A non-text attachment was scrubbed...
827 Name: 0001-Don-t-display-.-after-snippets-which-are-displayed-c.patch
828 Type: application/octet-stream
829 Size: 2085 bytes
830 Desc: not available
831 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100616/1123bd1c/attachment.obj>
832
833 From michael+sup@stapelberg.de Tue Jun 22 11:40:45 2010
834 From: michael+sup@stapelberg.de (Michael Stapelberg)
835 Date: Tue, 22 Jun 2010 17:40:45 +0200
836 Subject: [sup-devel] [PATCH] inline-gpg: call text_to_chunks on the text
837 before/after the GPG part
838 Message-ID: <1277221190-sup-946@midna.zekjur.net>
839
840 Hi,
841
842 quote from the commit message:
843
844 inline-gpg: call text_to_chunks on the text before/after the GPG part
845
846 This is necessary for stupid mailers which produce TOFU mails
847 containing unquoted inline gpg mails *argh*.
848
849
850 Best regards,
851 Michael
852 -------------- next part --------------
853 A non-text attachment was scrubbed...
854 Name: 0001-inline-gpg-call-text_to_chunks-on-the-text-before-af.patch
855 Type: application/octet-stream
856 Size: 2719 bytes
857 Desc: not available
858 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100622/2456115a/attachment-0001.obj>
859
860 From sascha-pgp@silbe.org Tue Jun 29 03:50:25 2010
861 From: sascha-pgp@silbe.org (Sascha Silbe)
862 Date: Tue, 29 Jun 2010 09:50:25 +0200
863 Subject: [sup-devel] [PATCH] fix reference to EncodingUnsupportedError
864 Message-ID: <1277797825-8181-1-git-send-email-sascha-pgp@silbe.org>
865
866 This fixes the following error:
867
868 ./lib/sup/message.rb:473:in `message_to_chunks': uninitialized constant Redwood::Message::EncodingUnsupportedError (NameError)
869
870 Signed-off-by: Sascha Silbe <sascha-pgp at silbe.org>
871 ---
872 lib/sup/message.rb | 2 +-
873 1 files changed, 1 insertions(+), 1 deletions(-)
874
875 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
876 index 4e6bbeb..1385585 100644
877 --- a/lib/sup/message.rb
878 +++ b/lib/sup/message.rb
879 @@ -470,7 +470,7 @@ private
880 when "7bit", "8bit", nil
881 m.body
882 else
883 - raise EncodingUnsupportedError, encoding.inspect
884 + raise RMail::EncodingUnsupportedError, encoding.inspect
885 end
886 body = body.normalize_whitespace
887 payload = RMail::Parser.read(body)
888 --
889 1.6.5
890
891
892 From sascha-pgp@silbe.org Tue Jun 29 04:04:54 2010
893 From: sascha-pgp@silbe.org (Sascha Silbe)
894 Date: Tue, 29 Jun 2010 10:04:54 +0200
895 Subject: [sup-devel] [PATCH] Don't choke when scanning message with unknown
896 encoding
897 Message-ID: <1277798694-8642-1-git-send-email-sascha-pgp@silbe.org>
898
899 This fixes the following error:
900
901 ./lib/sup/message.rb:473:in `message_to_chunks': "7BIT" (RMail::EncodingUnsupportedError)
902
903 when running sup-sync on a folder that contains a mail with these headers:
904
905 Content-Transfer-Encoding: 7bit
906 X-Mime-Autoconverted: from 8bit to 7bit by courier 0.60
907
908 Signed-off-by: Sascha Silbe <sascha-pgp at silbe.org>
909 ---
910 lib/sup/message.rb | 2 +-
911 1 files changed, 1 insertions(+), 1 deletions(-)
912
913 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
914 index 1385585..a13fc0c 100644
915 --- a/lib/sup/message.rb
916 +++ b/lib/sup/message.rb
917 @@ -259,7 +259,7 @@ class Message
918 rmsg = source.load_message(source_info)
919 parse_header rmsg.header
920 message_to_chunks rmsg
921 - rescue SourceError, SocketError => e
922 + rescue SourceError, SocketError, RMail::EncodingUnsupportedError => e
923 warn "problem getting messages from #{source}: #{e.message}"
924 ## we need force_to_top here otherwise this window will cover
925 ## up the error message one
926 --
927 1.6.5
928
929
930 From sascha-pgp@silbe.org Tue Jun 29 04:12:05 2010
931 From: sascha-pgp@silbe.org (Sascha Silbe)
932 Date: Tue, 29 Jun 2010 10:12:05 +0200
933 Subject: [sup-devel] [PATCH] fix crash in sup-dump if the default sent
934 source is used
935 Message-ID: <1277799125-8696-1-git-send-email-sascha-pgp@silbe.org>
936
937 This fixes a crash in sup-dump if the index contains a "sent" message and
938 no "sent" folder has been explicitly configured in the config file
939 (so it hasn't been added to sources.yaml).
940
941 Signed-off-by: Sascha Silbe <sascha-pgp at silbe.org>
942 ---
943 bin/sup-dump | 7 +++++++
944 1 files changed, 7 insertions(+), 0 deletions(-)
945
946 diff --git a/bin/sup-dump b/bin/sup-dump
947 index d6a06e4..953b6e5 100755
948 --- a/bin/sup-dump
949 +++ b/bin/sup-dump
950 @@ -19,9 +19,16 @@ Usage:
951 EOS
952 end
953
954 +$config = Redwood::load_config Redwood::CONFIG_FN
955 index = Redwood::Index.init
956 Redwood::SourceManager.init
957 index.load
958 +Redwood::SentManager.init $config[:sent_source] || 'sup://sent'
959 +if(s = Redwood::SourceManager.source_for Redwood::SentManager.source_uri)
960 + Redwood::SentManager.source = s
961 +else
962 + Redwood::SourceManager.add_source Redwood::SentManager.default_source
963 +end
964
965 index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m|
966 puts "#{m.id} (#{m.labels.to_a.sort_by { |l| l.to_s } * ' '})"
967 --
968 1.6.5
969
970
971 From sascha-ml-email-sup-devel@silbe.org Tue Jun 29 04:54:22 2010
972 From: sascha-ml-email-sup-devel@silbe.org (Sascha Silbe)
973 Date: Tue, 29 Jun 2010 08:54:22 +0000
974 Subject: [sup-devel] Will sup blow up after adding 10k sources?
975 Message-ID: <1277801600-sup-3476@twin.sascha.silbe.org>
976
977 Hi!
978
979 While fixing the sup-dump vs. default sent source bug (see posted patch) I stumbled over the following pieces of code:
980 1. SentManager uses source_id of 9998 for the default sent source
981 (lib/sup/sent.rb:52)
982 2. DraftManager uses a fixed source_id of 9999
983 (lib/sup/draft.rb:13,49)
984 3. SourceManager skips the source_id of SentManager and DraftManager
985 while computing the id for a new source (lib/sup/source.rb:203)
986
987 Does that mean sup will blow up once I have more than ~10k sources? I'm already at > 5k sources (containing > 680k messages, took > 2 days to import), so this isn't just an academic exercise...
988
989 Wouldn't it be better to (*) use small fixed source ids for SentManager/DraftManager and let SourceManager start above a number of reserved ids (say: 50)? Is there something in sup that depends on the non-special source ids not to have "holes" (or will waste resources in that case)?
990
991 Another approach would be to make the SentManager/DraftManager source ids dynamic and add them to sources.yaml.
992
993 Sascha
994
995 (*) Read: Would you accept a patch that implements that new logic?
996
997 --
998 http://sascha.silbe.org/
999 http://www.infra-silbe.de/
1000 -------------- next part --------------
1001 A non-text attachment was scrubbed...
1002 Name: signature.asc
1003 Type: application/pgp-signature
1004 Size: 490 bytes
1005 Desc: not available
1006 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100629/a6666680/attachment.bin>
1007
1008 From bwalton@artsci.utoronto.ca Tue Jun 29 09:15:56 2010
1009 From: bwalton@artsci.utoronto.ca (Ben Walton)
1010 Date: Tue, 29 Jun 2010 09:15:56 -0400
1011 Subject: [sup-devel] Will sup blow up after adding 10k sources?
1012 In-Reply-To: <1277801600-sup-3476@twin.sascha.silbe.org>
1013 References: <1277801600-sup-3476@twin.sascha.silbe.org>
1014 Message-ID: <1277817081-sup-1172@pinkfloyd.chass.utoronto.ca>
1015
1016 Excerpts from Sascha Silbe's message of Tue Jun 29 04:54:22 -0400 2010:
1017
1018 Hi Sascha,
1019
1020 > Wouldn't it be better to (*) use small fixed source ids for
1021 > SentManager/DraftManager and let SourceManager start above a number
1022 > of reserved ids (say: 50)? Is there something in sup that depends on
1023 > the non-special source ids not to have "holes" (or will waste
1024 > resources in that case)?
1025
1026 I agree that this would have been a better choice early on. Assign
1027 the lowest possible id's to the Sent/Draft sources and then hand out
1028 id's dynmaically from there.
1029
1030 > Another approach would be to make the SentManager/DraftManager
1031 > source ids dynamic and add them to sources.yaml.
1032
1033 I'd have to look, but changing these id's after they've been used will
1034 cause problems requiring a resync, I believe.
1035
1036 I'm sure others that have been more active in this part of the source
1037 lately can provide more info too.
1038
1039 HTH.
1040 -Ben
1041 --
1042 Ben Walton
1043 Systems Programmer - CHASS
1044 University of Toronto
1045 C:416.407.5610 | W:416.978.4302
1046
1047