mswatch-list Mailing List for mswatch
Brought to you by:
cfrost
Menu
▾
▴
mswatch-list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(34) |
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chris F. <ch...@fr...> - 2011-07-12 06:12:41
|
mswatch v1.2.0 is released; this is a feature release.
Changes:
- Add socketwatch program, to make mail synchronization more robust against
hangs (see mswatchrc.sample for use)
- Add optional occasional mailbox polling ("poll_period" in .mswatchrc), to
make mail synchronization more robust against silent aborts
- Add option to ignore changes to select mailboxes ("ignore" in .mswatchrc),
to reduce overheads for rarely-checked, high-volume mailing lists
- Update license to version 2, only, of the GNU GPL
Download: https://sourceforge.net/projects/mswatch/files/mswatch/1.2.0/mswatch-1.2.0.tar.gz/download
README: http://mswatch.sourceforge.net/dist/README
Project Homepage: http://mswatch.sourceforge.net/
--
Chris Frost
http://www.frostnet.net/chris/
|
|
From: Chris F. <ch...@fr...> - 2008-05-01 15:36:10
|
Running actions in the watchers is an interesting idea. Nice job on everything. I noticed a couple of the TODOs concern mswatch running a new OfflineIMAP instance for each sync, because each time a new network connection is established and python initializes itself. Pulling OfflineIMAP into the same process is a way to address these two problems, but I would suggest also considering running OfflineIMAP as a daemon and writing a small client program, which mswatch would invoke, that communicates with the OfflineIMAP daemon. This would resolve the two issues, with much weaker coupling of OfflineIMAP/python and mswatch/c++. -- Chris Frost | http://www.frostnet.net/chris/ -------------+-------------------------------- PGP: http://www.frostnet.net/chris/pgpkey.txt |
|
From: Ross P. <me...@rp...> - 2008-05-01 08:34:49
|
Like many others I've been frustrated with the options that are available for email clients. I recently had a bit of break through and packaged the reusable parts of my mail setup for consumption by others. See the backstory for all the gory details of the history. I've factored everything with an eye towards extensibility so if there's enough interest, I'll start a project and a public repo somewhere and put this out there. See the TODO list if your interested in any of the ideas I have for improvements. To try it out, just see the README_ on the pypi page. Here's a brief description. This package provides some scripts that wrap parts of mswatch and OfflineIMAP and integrate with Gnus to provide a local maildir that is synchronized with a remote maildir as changes occur, instead of polling on a regular basis. This provides for near instant delivery of new mail while also reducing resource utilization. Integration with the Emacs mail and newsreader, Gnus, is also provided in such a way that your single threaded Emacs process is blocked much less as changes occur to the maildirs. .. _README: http://pypi.python.org/pypi/rpatterson.mailsync Ross |
|
From: Chris F. <ch...@fr...> - 2007-03-28 03:02:41
|
On Mon, Mar 26, 2007 at 11:22:58AM +0200, Tino Keitel wrote: > Great, thanks. > > I'm using 1.0.3 with your patch now and a second inter_delay line with > some folders and so far it works. Super. I'll release these changes as 1.1.0. -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------------- PGP: <http://www.frostnet.net/chris/about/pgp_key.txt> |
|
From: Tino K. <tin...@ti...> - 2007-03-26 09:23:04
|
On Fri, Mar 23, 2007 at 01:21:11 -0700, Chris Frost wrote:
> On Mon, Mar 19, 2007 at 07:28:36PM +0100, Tino Keitel wrote:
> > attached is a slightly changed version of the patch. No functional
> > changes, just cleanups (removed an obsolete include, no global
> > non_ext_mailboxes variable, declared some iterator variables
> > function-wide).
>
> Thanks, Tino! I enhanced the change to support multiple delay classes
> (eg to also allow rapid sinks of low volume and important lists).
> If you happen to have a brief moment, could you test the attached
> patch?
Great, thanks.
I'm using 1.0.3 with your patch now and a second inter_delay line with
some folders and so far it works.
Regards,
Tino
|
|
From: Chris F. <ch...@fr...> - 2007-03-23 08:21:24
|
On Mon, Mar 19, 2007 at 07:28:36PM +0100, Tino Keitel wrote: > attached is a slightly changed version of the patch. No functional > changes, just cleanups (removed an obsolete include, no global > non_ext_mailboxes variable, declared some iterator variables > function-wide). Thanks, Tino! I enhanced the change to support multiple delay classes (eg to also allow rapid sinks of low volume and important lists). If you happen to have a brief moment, could you test the attached patch? Or if you happen to be using a svn checkout, it is r299. The additional inter_delay syntax (also in the man page): inter_delay 60 # default inter_delay 30 important inter_delay 600 lkml netdev The patch also allows inter_delays to be greater than the max error delay (there should be no reason to restrict these values so). thanks again! and sorry for the delay in my response, we just wrapped up a paper here at school, -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------------- PGP: <http://www.frostnet.net/chris/about/pgp_key.txt> |
|
From: Tino K. <tin...@ti...> - 2007-03-19 18:28:48
|
Hi, attached is a slightly changed version of the patch. No functional changes, just cleanups (removed an obsolete include, no global non_ext_mailboxes variable, declared some iterator variables function-wide). Regards, Tino |
|
From: Tino K. <tin...@ti...> - 2007-03-19 00:52:13
|
Hi again, ...and here is the patch. Regards, Tino |
|
From: Tino K. <tin...@ti...> - 2007-03-19 00:51:08
|
Hi folks, attached is a patch that adds settings for mailboxes that should only sync at longer intervals. It is intended for high traffic mailing lists that shouldn't disturb normal mail syncs. The settings are: extended_mailboxes extended_inter_delay Example: extended_inter_delay 300 extended_mailboxes lkml netdev This way, the mailboxes "lkml" and "netdev" get a longer minimum delay between syncs. The delay between syncs for these mailboxes will be at least 300 seconds, as long as no other mailbox changes in this time. If another mailbox changes, the folders specified in extended_mailboxes will also be synced. This feature was inspired by "Subject: rfc: per-mailbox sync delay time feature" from over an half year ago. Regards, Tino |
|
From: <Ti...@do...> - 2006-11-02 09:09:47
|
On Wed, Sep 13, 2006 at 21:44:15 -0700, Chris Frost wrote: > A few people have commented that being able to set sync delay times > on a per-mailbox basis would be helpful, e.g. set higher times for high > volume lists that one doesn't often read. I wanted to see if anyone > interested in such a feature has feedback on the below approach. > > > There would continue to be a default sync delay (base_delay in > mswatchrc-speak). There would be a new config option that specified > a non-default sync delay for a set of mailboxes, mailboxes given by name. > One may have multiple sets of these, to specify multiple non-default times. > > So an example of the above, using a conceptual syntax: > base_delay 10 > mailbox_delay 5 INBOX > mailbox_delay 600 spam high-volume-list This would be great. > When INBOX first changes a sync would be scheduled in 5s, spam or > high-volume-list in 600s, and a change to any other mailbox in 10s. > > The above may mean that mswatch would need to be restarted if a > mailbox is added while mswatch is running and one would like to > specify a non-default sync delay for the new mailbox. This seems > acceptable if it works out this way; or does anyone think not having > to restart mswatch would be of great help? I think this is a rare case, and restarting mswatch also does no harm to anything, except for the one full sync at the first run. > I imagine the above sounds fine, I expect these next two points to > be more likely wanting of feedback. > > First point: what happens when a mailbox is waiting for it sync time, > say 'spam' still has 500s until sync, and another mailbox has > activity, say 'INBOX'? When it comes time to sync 'INBOX', should > 'spam' also be synced? (That is, when should a sync sync all queued > mailboxes or just mailboxes that have reached their sync delay?) > 1. All queued plus: Mailboxes are always consistently synced > 2. All queued plus: The mail in 'spam' is transfered, getting it to > you sooner and it may remove the need for the later sync, reducing > the number of syncs > 3. All queued minus: Selecting the 'spam' mailbox for sync twice will > take slightly more time than selecting just once I would vote for "All queued", since the aim of the longer delays for certain mailboxes is to avoid the regular syncing for high traffic mailboxes so that other (and more important) mailboxes don't have to wait until the delay is over. > I think 1. shows syncing all queued makes using the mailboxes much > simpler and is reason enough to sync all queued mailboxes. Does > anyone see other reasons for/against or think mailboxes should be > synced only when their timeout expires? > > Second point: should mailbox names in mswatchrc permit pattern matching? > Allowing regexes would complicate the use of mailbox names > with special characters in them and one could, so there is of course a > solid reason to not allow patterns. My mail collection doesn't need and > couldn't benefit from this, but I could understand someone wanting this. > Someone say so if this might be the case? Not really. In my case, I only have a few defined mailboxes that I'd want to give a longer delay. Regards, Tino |
|
From: Chris F. <ch...@fr...> - 2006-09-14 04:44:22
|
A few people have commented that being able to set sync delay times on a per-mailbox basis would be helpful, e.g. set higher times for high volume lists that one doesn't often read. I wanted to see if anyone interested in such a feature has feedback on the below approach. There would continue to be a default sync delay (base_delay in mswatchrc-speak). There would be a new config option that specified a non-default sync delay for a set of mailboxes, mailboxes given by name. One may have multiple sets of these, to specify multiple non-default times. So an example of the above, using a conceptual syntax: base_delay 10 mailbox_delay 5 INBOX mailbox_delay 600 spam high-volume-list When INBOX first changes a sync would be scheduled in 5s, spam or high-volume-list in 600s, and a change to any other mailbox in 10s. The above may mean that mswatch would need to be restarted if a mailbox is added while mswatch is running and one would like to specify a non-default sync delay for the new mailbox. This seems acceptable if it works out this way; or does anyone think not having to restart mswatch would be of great help? I imagine the above sounds fine, I expect these next two points to be more likely wanting of feedback. First point: what happens when a mailbox is waiting for it sync time, say 'spam' still has 500s until sync, and another mailbox has activity, say 'INBOX'? When it comes time to sync 'INBOX', should 'spam' also be synced? (That is, when should a sync sync all queued mailboxes or just mailboxes that have reached their sync delay?) 1. All queued plus: Mailboxes are always consistently synced 2. All queued plus: The mail in 'spam' is transfered, getting it to you sooner and it may remove the need for the later sync, reducing the number of syncs 3. All queued minus: Selecting the 'spam' mailbox for sync twice will take slightly more time than selecting just once I think 1. shows syncing all queued makes using the mailboxes much simpler and is reason enough to sync all queued mailboxes. Does anyone see other reasons for/against or think mailboxes should be synced only when their timeout expires? Second point: should mailbox names in mswatchrc permit pattern matching? Allowing regexes would complicate the use of mailbox names with special characters in them and one could, so there is of course a solid reason to not allow patterns. My mail collection doesn't need and couldn't benefit from this, but I could understand someone wanting this. Someone say so if this might be the case? thanks for any feedback! -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------- Public PGP Key: Email ch...@fr... with the subject "retrieve pgp key" or visit <http://www.frostnet.net/chris/about/pgp_key.phtml> |
|
From: Tino K. <tin...@ti...> - 2006-09-01 07:32:38
|
On Thu, Aug 31, 2006 at 23:53:12 -0700, Chris Frost wrote: > On Thu, Aug 31, 2006 at 10:35:19AM +0200, Tino Keitel wrote: > > I accidently used a kernel (2.6.18-rc5) with CONFIG_INOTIFY enabled, > > but CONFIG_INOTIFY_USER disabled. This caused watch_maildirs to fail > > with the following message: > > > > inotify_init: Function not implemented > > > > Maybe watch_maildirs should fall back in this case. However, I don't > > know if is possible to detect this from the userspace. > > When watch_maildirs is configured it does detect whether inotify is supported, > falling back to testing for dnotify support. You are correct that > watch_maildirs is not currently able to fallback at runtime. Ah, ok. > This would make running and reporting bugs for mswatch more complicated, > but it also seems like the flexibility would be nice. Lack of inotify support > can be detected from userspace: if the function that initializes inotify for > the process fails then watch_maildirs could try to fallback to dnotify. > I just added this feature to mswatch's TODO list (r296). If having this > support sooner rather than later would be helpful for you just let me know > and I'll look into it more proactively. No reason to hurry. I just noticed it because I forgot a kernel option. But it would be mandatory is mswatch should be included in a binary distribiution. Regards, Tino |
|
From: Chris F. <ch...@fr...> - 2006-09-01 06:52:30
|
On Thu, Aug 31, 2006 at 10:35:19AM +0200, Tino Keitel wrote: > I accidently used a kernel (2.6.18-rc5) with CONFIG_INOTIFY enabled, > but CONFIG_INOTIFY_USER disabled. This caused watch_maildirs to fail > with the following message: > > inotify_init: Function not implemented > > Maybe watch_maildirs should fall back in this case. However, I don't > know if is possible to detect this from the userspace. When watch_maildirs is configured it does detect whether inotify is supported, falling back to testing for dnotify support. You are correct that watch_maildirs is not currently able to fallback at runtime. This would make running and reporting bugs for mswatch more complicated, but it also seems like the flexibility would be nice. Lack of inotify support can be detected from userspace: if the function that initializes inotify for the process fails then watch_maildirs could try to fallback to dnotify. I just added this feature to mswatch's TODO list (r296). If having this support sooner rather than later would be helpful for you just let me know and I'll look into it more proactively. -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------- Public PGP Key: Email ch...@fr... with the subject "retrieve pgp key" or visit <http://www.frostnet.net/chris/about/pgp_key.phtml> |
|
From: Tino K. <tin...@ti...> - 2006-08-31 08:35:31
|
Hi, I accidently used a kernel (2.6.18-rc5) with CONFIG_INOTIFY enabled, but CONFIG_INOTIFY_USER disabled. This caused watch_maildirs to fail with the following message: inotify_init: Function not implemented Maybe watch_maildirs should fall back in this case. However, I don't know if is possible to detect this from the userspace. Regards, Tino |
|
From: Daniel D. <dan...@gm...> - 2006-08-24 15:30:31
|
On Thursday 24 August 2006 15:35, Chris Frost wrote: > It does! (Or should; I'll believe you. ;) > did it not for you?) I wasn't sure, and also I didn't upgrade to 1.0.3 yet. But most probably it does. Thanks! |
|
From: Chris F. <ch...@fr...> - 2006-08-24 13:35:22
|
On Thu, Aug 24, 2006 at 01:36:49PM +0200, Daniel Danner wrote: > if mswatch is designed to do a complete resync when the remote watcher > recovers from an interrupted connection. > > If not, maybe it should do. ;) It does! (Or should; did it not for you?) -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------- Public PGP Key: Email ch...@fr... with the subject "retrieve pgp key" or visit <http://www.frostnet.net/chris/about/pgp_key.phtml> |
|
From: Daniel D. <dan...@gm...> - 2006-08-24 11:37:24
|
if mswatch is designed to do a complete resync when the remote watcher recovers from an interrupted connection. If not, maybe it should do. ;) |
|
From: Chris F. <ch...@fr...> - 2006-08-11 05:12:33
|
On Tue, Aug 08, 2006 at 11:24:30AM +0200, Tino Keitel wrote:
> On Mon, Aug 07, 2006 at 22:33:13 -0700, Chris Frost wrote:
>
> [...]
>
> > released it with mswatch 1.0.2. mswatch 1.0.2 also supports symlinks
> > to directories for folder names and {cur,new,tmp}.
>
> Hi,
>
> this doesn't seem to be the case, at least on XFS. In watch_maildirs.h,
> you use lstat() and check for S_ISDIR(). However, lstat() doesn't
> follow symlinks (contrary to your comment in watch_maildirs.h). If you
> use stat() instead of lstat(), the symlink target will be stat()ed and
> symlinks to maildirs work as expected.
>
> I just verified this behaviour on my XFS system.
>
> I just used lstat() in the patch I posted so that it doesn't change the
> known behaviour of watch_maildirs.
mswatch 1.0.3 should now correct symlink watching.
Directories can be watched through symlinks, but watch_maildirs does not
currently detect changes to the symlink itself (eg it disappears).
This will up the kernel requirements to 2.6.15 and isn't pressing because
mbsync does not propagate folder deletions (right now?), but I plan
to correct this in the not too far future.
--
Chris Frost | <http://www.frostnet.net/chris/>
-------------+----------------------------------
Public PGP Key:
Email ch...@fr... with the subject "retrieve pgp key"
or visit <http://www.frostnet.net/chris/about/pgp_key.phtml>
|
|
From: Chris F. <ch...@fr...> - 2006-08-10 06:03:58
|
On Wed, Aug 09, 2006 at 07:40:58PM +0200, Daniel Danner wrote: > On Wednesday 09 August 2006 18:06, Chris Frost wrote: > > How do these reasons sound to you? (If they happen to be convincing, > > do you have any thoughts on what the current documentation is missing?) > > Hmmm. I sounds sensible, except for the fact that requiring multiple > configuration files for a tool that is not meant to do several, totally > seperated jobs (in fact, it's a single job for a single user or machine: > provide mail syncing via mbsync) looks unintentional to me. > > I'd understand if you'd hesitate to rewrite the whole configuration syntax, > but in my opinion, it would be as fine as possible to achieve the same thing > you described in just one configuration file. Much more convenient. I think I'll leave the syntax as is, at least for now. If reasons to change this arise down the road, I'm definitely fine with making improvements. > > > Furthermore, it should absolute not be an error condition if there's only > > > one watcher. It may be not the normal case or "stupid", but it should be > > > legitimate for testing purposes. > > > > If you see having one watcher as useful only for testing, I think I prefer > > requiring two: > > - Workaround for testing: make the second watcher "sleep 60" or "cat > > fifo_file" - Benefit: mswatch can report configuration errors for the > > common case > > Agreed. But then you should add error handling which reports that mswatch > misses a second watcher. This error checking was intended; mswatch presently errors on zero or >2 store entries. The subversion code now errors on just 1 store the next mswatch release will include this update. -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------- Public PGP Key: Email ch...@fr... with the subject "retrieve pgp key" or visit <http://www.frostnet.net/chris/about/pgp_key.phtml> |
|
From: Daniel D. <dan...@gm...> - 2006-08-09 17:41:10
|
On Wednesday 09 August 2006 18:06, Chris Frost wrote: > How do these reasons sound to you? (If they happen to be convincing, > do you have any thoughts on what the current documentation is missing?) Hmmm. I sounds sensible, except for the fact that requiring multiple configuration files for a tool that is not meant to do several, totally seperated jobs (in fact, it's a single job for a single user or machine: provide mail syncing via mbsync) looks unintentional to me. I'd understand if you'd hesitate to rewrite the whole configuration syntax, but in my opinion, it would be as fine as possible to achieve the same thing you described in just one configuration file. Much more convenient. > > Furthermore, it should absolute not be an error condition if there's only > > one watcher. It may be not the normal case or "stupid", but it should be > > legitimate for testing purposes. > > If you see having one watcher as useful only for testing, I think I prefer > requiring two: > - Workaround for testing: make the second watcher "sleep 60" or "cat > fifo_file" - Benefit: mswatch can report configuration errors for the > common case Agreed. But then you should add error handling which reports that mswatch misses a second watcher. |
|
From: Tino K. <tin...@ti...> - 2006-08-09 16:24:46
|
On Wed, Aug 09, 2006 at 09:15:58 -0700, Chris Frost wrote: > On Wed, Aug 09, 2006 at 08:56:01AM +0200, Tino Keitel wrote: > > Another little thing: > > > > I run mswatch as a service in background. Logging is done via a logger > > that fetches stderr and stdout and writes it into a log file (with > > timestamps, size limit, log rotation etc.). However, this needs a > > setlinebuf(stdout); to be able to get immediate logging. Otherwise, the > > last output will be deferred until a fflush(). > > The next version of mswatch will do this; thanks. > > What program(s) do you use to do the log file work? svlogd, it is part of the runit[1] package. > Would it be helpful for mswatch to have a daemonize option that > detaches and logs to a file? I have no need for this. When it runs as a daemon, it can not be controlled by a service supervisor, like runit. If it logs to a file, an external program for logfile rotation is required, with all it's drawbacks, like file descriptors that are left open forever etc. The current state plus setlinebuf(stdout); would be perfect for me. :-) Regards, Tino [1] http://smarden.org/runit/ |
|
From: Chris F. <ch...@fr...> - 2006-08-09 16:16:05
|
On Wed, Aug 09, 2006 at 08:56:01AM +0200, Tino Keitel wrote: > Another little thing: > > I run mswatch as a service in background. Logging is done via a logger > that fetches stderr and stdout and writes it into a log file (with > timestamps, size limit, log rotation etc.). However, this needs a > setlinebuf(stdout); to be able to get immediate logging. Otherwise, the > last output will be deferred until a fflush(). The next version of mswatch will do this; thanks. What program(s) do you use to do the log file work? Would it be helpful for mswatch to have a daemonize option that detaches and logs to a file? -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------- Public PGP Key: Email ch...@fr... with the subject "retrieve pgp key" or visit <http://www.frostnet.net/chris/about/pgp_key.phtml> |
|
From: Chris F. <ch...@fr...> - 2006-08-09 16:07:05
|
On Wed, Aug 09, 2006 at 05:10:02PM +0200, Daniel Danner wrote:
> On Wednesday 09 August 2006 16:48, you wrote:
> > I intended for the wrong number of stores to cause an error at startup
> > and am planning making this happen in the next version of mswatch.
> > Do you think it would be helpful to convey the "two stores" requirement
> > in another way as well?
> > (Related, do you want to only watch one store? The two store requirement
> > is only self imposed, since it seemed this would be how everyone would
> > use mswatch.)
>
> I don't know, if this is what to want to know, but IMHO it would be much more
> clearly done that way:
>
> store mydomain
> {
> watch watch_maildirs
> watch ssh ...foo...
> }
>
> There's actually no need to define two stores, if they both use the same
> channel to sync with mbsync, right? So why not just define one store which
> can be invoked to start syncing by several (normally two) watchers.
A mswatch store is the same concept as a mbsync store (in mbysnc, MaildirStore
and IMAPStore). I think changing mswatch stores to be equivalent to mbsync
channels would be a mixture of terminology.
The intended mswatch usage is that for each mbsync channel there will be one
mswatchrc; this lets one set the mailbox_prefix, delays, and sync program
on a per-channel basis.
Also, mswatch store names entirely internal to mswatch; their only use is
to give error messages concerning the store's watcher.
How do these reasons sound to you? (If they happen to be convincing,
do you have any thoughts on what the current documentation is missing?)
> Furthermore, it should absolute not be an error condition if there's only one
> watcher. It may be not the normal case or "stupid", but it should be
> legitimate for testing purposes.
If you see having one watcher as useful only for testing, I think I prefer
requiring two:
- Workaround for testing: make the second watcher "sleep 60" or "cat fifo_file"
- Benefit: mswatch can report configuration errors for the common case
I can see that there might be uses for a single watcher (you only want
to sync when changes on one side occur) or >2 watchers (you want to keep
several mailstores in sync), but I have not come up with any cases of these
that I can actually see occurring.
> PS.: Would you please configure your mailing client to not CC the ones you
> reply to on this list? If suffices to reply to the list. Thanks. ;)
Sorry about that; I'll only reply to list, now.
--
Chris Frost | <http://www.frostnet.net/chris/>
-------------+----------------------------------
Public PGP Key:
Email ch...@fr... with the subject "retrieve pgp key"
or visit <http://www.frostnet.net/chris/about/pgp_key.phtml>
|
|
From: Daniel D. <dan...@gm...> - 2006-08-09 15:10:41
|
On Wednesday 09 August 2006 16:48, you wrote:
> I intended for the wrong number of stores to cause an error at startup
> and am planning making this happen in the next version of mswatch.
> Do you think it would be helpful to convey the "two stores" requirement
> in another way as well?
> (Related, do you want to only watch one store? The two store requirement
> is only self imposed, since it seemed this would be how everyone would
> use mswatch.)
I don't know, if this is what to want to know, but IMHO it would be much more
clearly done that way:
store mydomain
{
watch watch_maildirs
watch ssh ...foo...
}
There's actually no need to define two stores, if they both use the same
channel to sync with mbsync, right? So why not just define one store which
can be invoked to start syncing by several (normally two) watchers.
Just my two unqualified cents. ;)
Furthermore, it should absolute not be an error condition if there's only one
watcher. It may be not the normal case or "stupid", but it should be
legitimate for testing purposes.
Regards,
Daniel
PS.: Would you please configure your mailing client to not CC the ones you
reply to on this list? If suffices to reply to the list. Thanks. ;)
|
|
From: Chris F. <ch...@fr...> - 2006-08-09 14:48:59
|
On Wed, Aug 09, 2006 at 04:39:31PM +0200, Daniel Danner wrote: > On Wednesday 09 August 2006 15:41, Tino Keitel wrote: > > I would say that there is a remote store missing in your config file. > > In the sample config file, it is called "store mydomain". > > You're right. 0:-) > > But you have to admit, that this requirement isn't shown clearly in the sample > config. IMHO. I intended for the wrong number of stores to cause an error at startup and am planning making this happen in the next version of mswatch. Do you think it would be helpful to convey the "two stores" requirement in another way as well? (Related, do you want to only watch one store? The two store requirement is only self imposed, since it seemed this would be how everyone would use mswatch.) -- Chris Frost | <http://www.frostnet.net/chris/> -------------+---------------------------------- Public PGP Key: Email ch...@fr... with the subject "retrieve pgp key" or visit <http://www.frostnet.net/chris/about/pgp_key.phtml> |
