Re: [Abook-devel] [patch] custom output format

[Raphaël <rap...@gm...>]

On Mon, Jul 25, 2011 at 11:30:11PM -0800, Roger wrote:
> Sounds neat.
> 
> I usually just do:
> 
> $ cat .abook/addressbook |less 
> 
> And type: /name_to_find

The aim of a nice formatting command-line syntax is to allow
others tools/script to benefit from abook (in non-interactive mode).
I have currently the following use-case in mind:

When sending sms with gnokii/bluetooth, I would like the nickname to be
auto-completed from abook (with the mobile phone number)
For this to work, abook should be able to understand which fields have
to be returned (in this case: the NAME (for the completion) + the MOBILE
phone number).
That was the rational for the current patch.


Second point, I also think that abook may handle a specification of the
*fields* to be searched.
Currently --mutt-query hardcodes the following: NAME, EMAIL, NICK.

It may not be enough in some cases, eg, I have contacts which won't get
into my mobile phonebook (email/mutt only contacts).
With custom fields (already existing) + a simple query language :), I should
be able to build a phonebook .vcf file only containing contacts whose
"customfieldX" = "phone", so the next time I'm being stolen my mobile
phone, I'll regenerate it easily.


The alternative (workaround) to a field specification syntax is
to return every fields (to csv) then |grep/awk then repipe to:
|abook --convert --informat csv --outformat custom # (or a manual
regexp substitution tool)
Would it be a misuse of abook ?

Or does one knows of a simple library which would already implements a
simple query language ( <fields> {=|<>|[NOT ]CONTAINS} [AND|OR ...] ).
It would make abook more flexible and a very usable PIM source for others
applications.


As a last point, for every output filter to be also used on the restricted set of
entries (= with --mutt-query) (vs the whole phonebook), they need to
implement 2 functions:
- the already existing XXX_export_database(); (which adds
header/footer/... + custom conditions)
- one which returns the conversion on a per-entry basis, kind of
XXX_export_item();

It would nicely obsoletes the struct abook_output_filter u_filters[]
duplication I've made in the patch, but it would require that every
current output filters to be split into two functions.


advises ?


regards

Raph