Re: opening attachment

2010-10-12 Thread Michal Sojka
On Sun, 10 Oct 2010, Daniel Goldin wrote:
 
 Setting my .mailcap doesn't seem to have any effect on how notmuch/emacs
 handles attachments. Hitting return saves no matter what.

I use 'v' key to display attachments. This shows all attachments at
once with the programs configured in .mailcap.

-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: First draft of logging functionality.

2010-10-12 Thread Michal Sojka
On Mon, 11 Oct 2010, da...@tethera.net wrote:
 The patches following this message are my first attempt at
 implementing atomic logging for notmuch.  The idea is that such logs
 could be useful in synchronizing notmuch instances.
 
 Feedback of any kind is welcome. I'm particularly interested in
 comments about the log format and performance.

Hi David,

I'm not sure whether implementing logging facility outside of notmuch
library is a good thing. If somebody will use a third-party tool (such
as python bindings) to manipulate his tags, they won't appear in the
log.

-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch-next branch

2010-10-12 Thread Sebastian Spaeth
On 2010-10-11, Jesse Rosenthal wrote:
 I don't know how official this has to be -- just an agreed upon branch
 that people keep around next to their own personal one. Sebastian used
 to have one that served this purpose a while back, I think.

Well, it wasn't really semi-official or even blessed, I just announced
it loudest :-). Meanwhile, I don't feel like maintaining my own notmuch
anymore. I am still using it though and would love to follow someone's
branch :-).

Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: First draft of logging functionality.

2010-10-12 Thread Michal Sojka
On Tue, 12 Oct 2010, David Bremner wrote:
 On Tue, 12 Oct 2010 11:06:17 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
 
  I'm not sure whether implementing logging facility outside of notmuch
  library is a good thing. If somebody will use a third-party tool (such
  as python bindings) to manipulate his tags, they won't appear in the
  log.
 
 Yeah, thanks for that. I had been worrying about the same thing, but
 your message helped clarify things for me.
 
 I guess log files should be opened in notmuch_database_open, and the
 actual logging in this case could happen from notmuch_message_add_tag.
 
 From an atomicity point of view it might make more sense to store up a
 list of log lines, and dump them all from _notmuch_message_sync.
 One could attach a log buffer to a message, and flush that atomically
 when syncing the message back to the database.

Yes, the above sounds good to me.

 In this context, it is a little more tedious to have more than one log
 file.

Why multiple log files? You may have the buffers for message logs in
memory, right?

Another thing to keep in mind is how it will behave with 'notmuch
restore'. If do dump followed by resore you will have a very long log
with no useful information in it. Some optimization may be employed here.

Bye
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: First draft of logging functionality.

2010-10-12 Thread Rob Browning
da...@tethera.net writes:

 The patches following this message are my first attempt at
 implementing atomic logging for notmuch.  The idea is that such logs
 could be useful in synchronizing notmuch instances.

For this to be completely safe, I suspect it may need to be adjusted to
do write ahead logging or something similar.  Otherwise operations could
be lost.

i.e. notmuch would atomically and safely write the intended (tag)
operation to the log, then perform the tag.  On startup, notmuch would
need to scan the log to detect and apply operations that hadn't been
fully completed (presumably due to a crash).

More generally, while thinking about sync/logging a few days ago, I
wondered about using sqlite.  That would help with atomicity, rollback,
synchronizing multiple readers/writers, etc.  It might also make
operations more efficient once we implement all the features we want.

For example, with the log information in sqlite, a separate notmuch sync
to another machine could be reading from the log (and with limitations,
writing) in parallel with normal notmuch operations.  Depending on how
we decide to handle sync with multiple peers, the log may also need to
track which peers have seen what, prune appropriately, etc.

Of course sqlite may not be appropriate, and would require performance
testing, etc., but we should probably think about the features we'll
eventually want, and consider how much work they're likely to require
with any given approach, regardless.

Hope this helps
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch-next branch

2010-10-12 Thread Carl Worth
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras 
felipe.contre...@gmail.com wrote:
 I'm proposing to have notmuch-next branch, either on github or
 gitorious (please vote).

I'd be glad to host something on notmuchmail.org too.

I suppose I should just set that up...

-Carl


pgp5KIeDjUuhO.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch-next branch

2010-10-12 Thread David Bremner
On Tue, 12 Oct 2010 16:19:35 -0700, Carl Worth cwo...@cworth.org wrote:
 On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras 
 felipe.contre...@gmail.com wrote:
  I'm proposing to have notmuch-next branch, either on github or
  gitorious (please vote).
 
 I'd be glad to host something on notmuchmail.org too.
 
 I suppose I should just set that up...
 

+1 for carl just setting that up :)

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


notmuch-next branch

2010-10-12 Thread Felipe Contreras
On Mon, Oct 11, 2010 at 10:01 PM, Jameson Rollins
 wrote:
> On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras  gmail.com> wrote:
>> I think many people agree notmuch mainline has been rather slow. So
>> I'm proposing to have notmuch-next branch, either on github or
>> gitorious (please vote).
>>
>> More than one person should have write access to this repo, but some
>> guidelines should be in place. I propose that patches should be
>> signed-off-by at least another person in the mailing list before
>> pushing. It would be nice if this is how the mainline branch works,
>> but we don't need to wait for that to happen. We need to vote on who
>> are the people to have write access.
>
> I think this generally sounds like a fine idea, but I don't see why we
> need a single central repo that multiple people need access to. ?The
> whole point of git is to allow for distributed development without need
> for a central repo.

And yet, git is hosted in a central repo. Different projects have
different needs, and this one seems to need a place to cook up
patches, having multiple committers there seems like it would work.
Note that this wouldn't be the main repo, it would be preparing stage.

> In this case, folks can just merge the patches they're interested in
> into a "next" branch in their own personal repos, publish them where
> ever they want, and then every body can just keep their "next" branches
> synced with each other. ?As consensus is reached, the next release will
> emerge.

That might also work, it would be the first project I see doing that
though. But what I worry is the ordering of the patches; we might have
applied the same patches, but they would appear as totally different
branches to a 3rd party, and of course merging other people's 'next'
branches would create a total mess. There should be one repo that has
the latest and greatest 'next' branch that everybody can rebase into,
like the current 'master'.

-- 
Felipe Contreras


opening attachment

2010-10-12 Thread Michal Sojka
On Sun, 10 Oct 2010, Daniel Goldin wrote:
> 
> Setting my .mailcap doesn't seem to have any effect on how notmuch/emacs
> handles attachments. Hitting return saves no matter what.

I use 'v' key to display attachments. This shows all attachments at
once with the programs configured in .mailcap.

-Michal


First draft of logging functionality.

2010-10-12 Thread Michal Sojka
On Mon, 11 Oct 2010, david at tethera.net wrote:
> The patches following this message are my first attempt at
> implementing atomic logging for notmuch.  The idea is that such logs
> could be useful in synchronizing notmuch instances.
> 
> Feedback of any kind is welcome. I'm particularly interested in
> comments about the log format and performance.

Hi David,

I'm not sure whether implementing logging facility outside of notmuch
library is a good thing. If somebody will use a third-party tool (such
as python bindings) to manipulate his tags, they won't appear in the
log.

-Michal


notmuch-next branch

2010-10-12 Thread Sebastian Spaeth
On 2010-10-11, Jesse Rosenthal wrote:
> I don't know how official this has to be -- just an agreed upon branch
> that people keep around next to their own personal one. Sebastian used
> to have one that served this purpose a while back, I think.

Well, it wasn't really semi-official or even blessed, I just announced
it loudest :-). Meanwhile, I don't feel like maintaining my own notmuch
anymore. I am still using it though and would love to follow someone's
branch :-).

Sebastian


First draft of logging functionality.

2010-10-12 Thread David Bremner
On Tue, 12 Oct 2010 11:06:17 +0200, Michal Sojka  wrote:

> I'm not sure whether implementing logging facility outside of notmuch
> library is a good thing. If somebody will use a third-party tool (such
> as python bindings) to manipulate his tags, they won't appear in the
> log.

Yeah, thanks for that. I had been worrying about the same thing, but
your message helped clarify things for me.

I guess log files should be opened in notmuch_database_open, and the
actual logging in this case could happen from notmuch_message_add_tag.

>From an atomicity point of view it might make more sense to store up a
list of log lines, and dump them all from _notmuch_message_sync.
One could attach a log buffer to a message, and flush that atomically
when syncing the message back to the database. In this context, it is a
little more tedious to have more than one log file. 

d


First draft of logging functionality.

2010-10-12 Thread Michal Sojka
On Tue, 12 Oct 2010, David Bremner wrote:
> On Tue, 12 Oct 2010 11:06:17 +0200, Michal Sojka  
> wrote:
> 
> > I'm not sure whether implementing logging facility outside of notmuch
> > library is a good thing. If somebody will use a third-party tool (such
> > as python bindings) to manipulate his tags, they won't appear in the
> > log.
> 
> Yeah, thanks for that. I had been worrying about the same thing, but
> your message helped clarify things for me.
> 
> I guess log files should be opened in notmuch_database_open, and the
> actual logging in this case could happen from notmuch_message_add_tag.
> 
> From an atomicity point of view it might make more sense to store up a
> list of log lines, and dump them all from _notmuch_message_sync.
> One could attach a log buffer to a message, and flush that atomically
> when syncing the message back to the database.

Yes, the above sounds good to me.

> In this context, it is a little more tedious to have more than one log
> file.

Why multiple log files? You may have the buffers for message logs in
memory, right?

Another thing to keep in mind is how it will behave with 'notmuch
restore'. If do dump followed by resore you will have a very long log
with no useful information in it. Some optimization may be employed here.

Bye
-Michal


First draft of logging functionality.

2010-10-12 Thread David Bremner
On Tue, 12 Oct 2010 13:38:42 +0200, Michal Sojka  wrote:
> 
> Why multiple log files? You may have the buffers for message logs in
> memory, right?

Well, maybe one log for tag operations, one for adding messages, etc... 
But it is easy enough to mark log entries by what they are.

> 
> Another thing to keep in mind is how it will behave with 'notmuch
> restore'. If do dump followed by resore you will have a very long log
> with no useful information in it. Some optimization may be employed here.
> 

Yes. This seems hard to optimize internally, but I was thinking of some
"log compression" function that comes up with a minimal equivalent set
of operations. I had in mind that this could be used to sync:
concatenate all the logs, and then compress to a minimal set of
operations.  This is still not completely thought out...
Another issue is that the buffer could get rather big during a restore,
but this is presumably fixable by flushing it if it gets too large.

All the best,

David


notmuch-next branch

2010-10-12 Thread Carl Worth
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras  wrote:
> I'm proposing to have notmuch-next branch, either on github or
> gitorious (please vote).

I'd be glad to host something on notmuchmail.org too.

I suppose I should just set that up...

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101012/579786a8/attachment.pgp>


notmuch-next branch

2010-10-12 Thread David Bremner
On Tue, 12 Oct 2010 16:19:35 -0700, Carl Worth  wrote:
> On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras  gmail.com> wrote:
> > I'm proposing to have notmuch-next branch, either on github or
> > gitorious (please vote).
> 
> I'd be glad to host something on notmuchmail.org too.
> 
> I suppose I should just set that up...
> 

+1 for carl just setting that up :)

d