[notmuch] Using notmuch from Ruby, Python, et al.

[Mikhail Gusarov]

Twas brillig at 18:55:28 27.11.2009 UTC-08 when cworth at cworth.org did gyre 
and gimble:

 >> Q: Why are my replies five sentences or less?
 >> A: http://five.sentenc.es/

 CW> There---just five this time. :-)

I imagine hook that counts the number of sentences and inserts proper
signature :)

-- 
  http://fossarchy.blogspot.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: 

Re: [notmuch] Using notmuch from Ruby, Python, et al.

[Mikhail Gusarov]

Twas brillig at 18:55:28 27.11.2009 UTC-08 when cwo...@cworth.org did gyre and 
gimble:

 >> Q: Why are my replies five sentences or less?
 >> A: http://five.sentenc.es/

 CW> There---just five this time. :-)

I imagine hook that counts the number of sentences and inserts proper
signature :)

-- 
  http://fossarchy.blogspot.com/


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

Re: [notmuch] Using notmuch from Ruby, Python, et al.

[Carl Worth]

On Wed, 25 Nov 2009 09:58:00 -0800, Scott Robinson  wrote:
> Excerpts from Jeffrey Ollie's message of Wed Nov 25 09:46:47 -0800 2009:
> 
> I selected cJSON because it was simple for integration. Given how libsha1.c is
> included in lib/, I figured adding a depedency wouldn't be very
> popular.

I'm not dead-set against additional dependencies, but I think I do take
a conservative approach, (hence copying in the tiny libsha1.c rather
than linking to any enormous encryption library).

> Would it be better to link with a previously existing library?

For something like this, I don't see the need for any library at
all---generating any particular format is always *much* easier than
parsing it.

So I wouldn't mind seeing a couple of tiny functions in notmuch for this
(or other formats). And I think it would be better to start with code
that's already written and debugged (and license compatible!) rather
than starting from scratch.

> Q: Why are my replies five sentences or less?
> A: http://five.sentenc.es/

There---just five this time. :-)

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

[notmuch] Using notmuch from Ruby, Python, et al.

[Carl Worth]

On Wed, 25 Nov 2009 09:58:00 -0800, Scott Robinson  
wrote:
> Excerpts from Jeffrey Ollie's message of Wed Nov 25 09:46:47 -0800 2009:
> 
> I selected cJSON because it was simple for integration. Given how libsha1.c is
> included in lib/, I figured adding a depedency wouldn't be very
> popular.

I'm not dead-set against additional dependencies, but I think I do take
a conservative approach, (hence copying in the tiny libsha1.c rather
than linking to any enormous encryption library).

> Would it be better to link with a previously existing library?

For something like this, I don't see the need for any library at
all---generating any particular format is always *much* easier than
parsing it.

So I wouldn't mind seeing a couple of tiny functions in notmuch for this
(or other formats). And I think it would be better to start with code
that's already written and debugged (and license compatible!) rather
than starting from scratch.

> Q: Why are my replies five sentences or less?
> A: http://five.sentenc.es/

There---just five this time. :-)

-Carl

Re: [notmuch] Using notmuch from Ruby, Python, et al.

[Carl Worth]

On Wed, 25 Nov 2009 08:16:54 -0800, Scott Robinson  wrote:
> I'm hoping this thread will provide a guide for my efforts.
> 
> I'm writing a web frontend for notmuch in Ruby. But, the output from the
> notmuch command-line is ambiguous. Therefore, I've started two branches
> experimenting with different ways of providing hooks.

Hi Scott, welcome to notmuch!

A web frontend sounds very interesting, and I'll look forward to see
what you come up with here.

> Which of these approaches are likely to be pulled upstream?

Both, in fact!

> == Shared Library
> 
> I have modified the build to output a shared library. It's a small change
> relying on libtool.

We definitely want to have a shared library at some point. To some
extent, publishing a shared library commits us to maintaining API/ABI
for that library, and that's something I'm not willing to commit to
at this point, (since we're still seeing a fair amount of churn in the
interface).

But then again, we're also not even putting out a tar-file release yet
either, so I think it's easy to say that we're not "publishing" anything
yet and the API is all still subject to change.

> However, the archives indicate Carl dislikes libtool?

I've been maintaining a mainstream library (cairo) for several years
that uses libtool in its build system. So I know what that's like and I
definitely don't like it.

I haven't yet tried maintaining a library without using libtool, but I'm
optimistic that it will be much less painful, so that's what I'd like to
do for now.

> == JSON output
> 
> I added a --output=(text|json) option to "search" and "show." Then, emit json
> results appropriately.
> 
> To accomplish this, I used the cJSON library sans parsing logic.
> 
> However, I saw discussion about providing a --format option?

Obviously the exact name isn't that important and is easy to change. But
yes, this kind of thing looks very interesting.

> Q: Why are my replies five sentences or less?
> A: http://five.sentenc.es/

I guess I lose (or you do since you're the one receiving it). I count
this as sentence number 13 in my reply. :-)

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

[notmuch] Using notmuch from Ruby, Python, et al.

[Carl Worth]

On Wed, 25 Nov 2009 08:16:54 -0800, Scott Robinson  
wrote:
> I'm hoping this thread will provide a guide for my efforts.
> 
> I'm writing a web frontend for notmuch in Ruby. But, the output from the
> notmuch command-line is ambiguous. Therefore, I've started two branches
> experimenting with different ways of providing hooks.

Hi Scott, welcome to notmuch!

A web frontend sounds very interesting, and I'll look forward to see
what you come up with here.

> Which of these approaches are likely to be pulled upstream?

Both, in fact!

> == Shared Library
> 
> I have modified the build to output a shared library. It's a small change
> relying on libtool.

We definitely want to have a shared library at some point. To some
extent, publishing a shared library commits us to maintaining API/ABI
for that library, and that's something I'm not willing to commit to
at this point, (since we're still seeing a fair amount of churn in the
interface).

But then again, we're also not even putting out a tar-file release yet
either, so I think it's easy to say that we're not "publishing" anything
yet and the API is all still subject to change.

> However, the archives indicate Carl dislikes libtool?

I've been maintaining a mainstream library (cairo) for several years
that uses libtool in its build system. So I know what that's like and I
definitely don't like it.

I haven't yet tried maintaining a library without using libtool, but I'm
optimistic that it will be much less painful, so that's what I'd like to
do for now.

> == JSON output
> 
> I added a --output=(text|json) option to "search" and "show." Then, emit json
> results appropriately.
> 
> To accomplish this, I used the cJSON library sans parsing logic.
> 
> However, I saw discussion about providing a --format option?

Obviously the exact name isn't that important and is easy to change. But
yes, this kind of thing looks very interesting.

> Q: Why are my replies five sentences or less?
> A: http://five.sentenc.es/

I guess I lose (or you do since you're the one receiving it). I count
this as sentence number 13 in my reply. :-)

-Carl

[notmuch] Using notmuch from Ruby, Python, et al.

[Jeffrey Ollie]

On Wed, Nov 25, 2009 at 11:58 AM, Scott Robinson  wrote:
>
> I selected cJSON because it was simple for integration. Given how libsha1.c is
> included in lib/, I figured adding a depedency wouldn't be very popular.

Oh, I noticed libsha1.c as well, and it bugs the heck out of me.  I
just haven't gotten around to doing anything about it yet.

> Would it be better to link with a previously existing library?

IMHO yes.  I was looking at json-glib because it seems to be the only
C JSON API in Fedora, plus it's based upon glib.  From what I've read
it should be really easy to serialize a GMimeObject to a JSON
structure with very few calls using json-glib.

-- 
Jeff Ollie

[notmuch] Using notmuch from Ruby, Python, et al.

[Jeffrey Ollie]

On Wed, Nov 25, 2009 at 11:40 AM, Scott Robinson  wrote:
>
> As the json work is a bit more substantial, is it preferable to start a 
> [PATCH]
> thread or link to a git repo?

Probably a new [PATCH] thread so that the changes can be discussed.

-- 
Jeff Ollie

[notmuch] Using notmuch from Ruby, Python, et al.

[Jeffrey Ollie]

On Wed, Nov 25, 2009 at 10:16 AM, Scott Robinson  wrote:
>
> To accomplish this, I used the cJSON library sans parsing logic.

I wasn't familiar with cJSON so I went over to take a look.  I haven't
really examined the code, but I really don't like the fact that you
are expected to copy the cJSON code into your project.

-- 
Jeff Ollie

[notmuch] Using notmuch from Ruby, Python, et al.

[Jeffrey Ollie]

On Wed, Nov 25, 2009 at 10:16 AM, Scott Robinson  wrote:
>
> == Shared Library
>
> I have modified the build to output a shared library. It's a small change
> relying on libtool.
>
> However, the archives indicate Carl dislikes libtool?

Ugh, please, let's not go down the autoconf/automake/libtool route.

> == JSON output
>
> I added a --output=(text|json) option to "search" and "show." Then, emit json
> results appropriately.
>
> To accomplish this, I used the cJSON library sans parsing logic.
>
> However, I saw discussion about providing a --format option?

Awesome, I was just looking at using json-glib but I haven't gotten
very far yet, mainly because I've never used it before (nor done much
of anything with JSON). I was going to call the option
'--output-format=(standard|json)' but I'm not going to worry about the
color of that bikeshed.

IMHO, I think both approaches would be valuable, that way people
writing front ends could choose the methods that worked best for them.
 Do you have patches that you are ready to share?

-- 
Jeff Ollie

[notmuch] Using notmuch from Ruby, Python, et al.

[Scott Robinson]

Excerpts from Jeffrey Ollie's message of Wed Nov 25 10:03:05 -0800 2009:
> On Wed, Nov 25, 2009 at 11:58 AM, Scott Robinson  
> wrote:
> > Would it be better to link with a previously existing library?
> 
> IMHO yes.  I was looking at json-glib because it seems to be the only
> C JSON API in Fedora, plus it's based upon glib.  From what I've read
> it should be really easy to serialize a GMimeObject to a JSON
> structure with very few calls using json-glib.

I'm taking a look at json-glib now.

But, it doesn't look to support streaming output.
-- 
Scott Robinson | http://quadhome.com/

Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/

[notmuch] Using notmuch from Ruby, Python, et al.

[Scott Robinson]

Excerpts from Jeffrey Ollie's message of Wed Nov 25 09:46:47 -0800 2009:
> On Wed, Nov 25, 2009 at 10:16 AM, Scott Robinson  
> wrote:
> >
> > To accomplish this, I used the cJSON library sans parsing logic.
> 
> I wasn't familiar with cJSON so I went over to take a look.  I haven't
> really examined the code, but I really don't like the fact that you
> are expected to copy the cJSON code into your project.

I selected cJSON because it was simple for integration. Given how libsha1.c is
included in lib/, I figured adding a depedency wouldn't be very popular.

Would it be better to link with a previously existing library?
-- 
Scott Robinson | http://quadhome.com/

Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/

[notmuch] Using notmuch from Ruby, Python, et al.

[Scott Robinson]

Excerpts from Jeffrey Ollie's message of Wed Nov 25 08:33:39 -0800 2009:
> On Wed, Nov 25, 2009 at 10:16 AM, Scott Robinson  
> wrote:
> >
> > == Shared Library
> >
> > I have modified the build to output a shared library. It's a small change
> > relying on libtool.
> >
> > However, the archives indicate Carl dislikes libtool?
> 
> Ugh, please, let's not go down the autoconf/automake/libtool route.

I didn't use autoconf and friends. Just put in libtool where $(CXX) and $(CC)
are. Going with the system defaults.

See the attached patch.

> > == JSON output
> >
> > I added a --output=(text|json) option to "search" and "show." Then, emit 
> > json
> > results appropriately.
> >
> > To accomplish this, I used the cJSON library sans parsing logic.
> >
> > However, I saw discussion about providing a --format option?
> 
> Awesome, I was just looking at using json-glib but I haven't gotten
> very far yet, mainly because I've never used it before (nor done much
> of anything with JSON). I was going to call the option
> '--output-format=(standard|json)' but I'm not going to worry about the
> color of that bikeshed.
> 
> IMHO, I think both approaches would be valuable, that way people
> writing front ends could choose the methods that worked best for them.
>  Do you have patches that you are ready to share?
> 

Yes!

As the json work is a bit more substantial, is it preferable to start a [PATCH]
thread or link to a git repo?
-- 
Scott Robinson | http://quadhome.com/

Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/
-- next part --
A non-text attachment was scrubbed...
Name: libtoolize-notmuch.diff
Type: application/octet-stream
Size: 3996 bytes
Desc: not available
URL: 

[notmuch] Using notmuch from Ruby, Python, et al.

[Scott Robinson]

I'm hoping this thread will provide a guide for my efforts.

I'm writing a web frontend for notmuch in Ruby. But, the output from the
notmuch command-line is ambiguous. Therefore, I've started two branches
experimenting with different ways of providing hooks.

Which of these approaches are likely to be pulled upstream?

== Shared Library

I have modified the build to output a shared library. It's a small change
relying on libtool.

However, the archives indicate Carl dislikes libtool?

== JSON output

I added a --output=(text|json) option to "search" and "show." Then, emit json
results appropriately.

To accomplish this, I used the cJSON library sans parsing logic.

However, I saw discussion about providing a --format option?
-- 
Scott Robinson | http://quadhome.com/

Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/