Re: [hylafax-users] Hylafax DB integration (postgresql) and/or API

[Bill Binko <bill-sender-4b2fd6@xxxxxxxxx>]

On Wed, 11 Aug 2004, Lee Howard wrote:

> On 2004.08.11 23:26 doktora v wrote:
> > Well maybe it's just me but I haven't found any scripts.
>
> I think that Adam was referring to things like notify and faxrcvd which
> are shell scripts and can easily be modified.  That said, I don't think
> that's what you are looking for, as it sounds like your ambitions are
> higher.
>
> > Anyway I tend
> > to dislike scripts (just personal), and I want to give my
> > application/database access to hylafax information.
> >

I have also written scripts to do this type of integration.  Because of
the environment our database runs in (PHP/PostgreSQL), this involves
calling PHP scripts from FaxDispatch and notify (now FaxNotify) and quite
a bit of bubble gum and duct tape.

To be honest, it would be nice if stuff like logging, communication
records, and even the images were able to be stored in a database, but
more important to us was to be able to tightly integrate received faxes
with the current customer database.

The big thing with that was to recognize the calling number or destination
and match it with a stored fax number in the database.  When this was
found, we could attach it (as PDF) onto the customer's record.  We match
about 45% of inbound and 65% of outbound (most others are non-customer
contacts) and it has done wonders for followup and dispute resolution.

Because of my experience, I would bet that most people who want database
integration want tight integration with an existing or at least
in-progress application (perhaps I'm wrong, but it's where I am).

The biggest problem I see is that you have read and understand the current
scripts before you can do any custom work.  They're better in 4.2.0
(much!), but their still fairly complicated scripts, and at the very least
it is reasonable to be afraid of breaking them, or of losing your
modifications at upgrade time.

What would help me most here wouldn't be moving to a standard database
repository, but a set of well defined "hooks" where people could insert
the functionality they need.  (FaxNotify and FaxDispatch are primitive
versions of what I'm talking about here).  These would have a well-defined
interface, and it would be possible to register applications to be called
when those hooks were triggered without modifying any of the default
functionality or scripts (i.e. you'd define a hooks.conf file that said
what to call when, and that wouldn't be overwritten during upgrade).

Some points for those hooks (in no particular order) might be:

1) Inbound call: determine whether to answer (like current CID
black/whitelisting).  Needs to send at least CID info.  Could also allow
the hook to setup "capabilities" instead of the flat files.

2) Message to Log: Syslog would be the obvious first client for this, but
this could be abstracted fairly simply, and there are several other useful
targets.

3) Fax Received: The current "faxrcvd" script would fit into this type of
hook, except that it would be nice if there were separate hooks for
separate status (i.e. Partial Fax received).  If that stayed a parameter,
I could live with it.  There could very well be several hooks like this:
one before (or instead of) notification, one after, etc.

4) Outbound call requested: Similar to #1 above, allow the hook to set
things like priority, capabilities, modem pool, etc.  This would be prior
to queueing.

5) Outbound attempt: Each attempt could trigger this hook, before, after
or both.

6) Outbound complete: Again, perhaps this is really several (based on
result), but at the least, it needs to allow you to replace or augment
what "notify" does cleanly.

7) Outbound Fax Archived: needs to at least let you cleanly replace what
'archive' does.  (Also, this really needs to apply to inbound and outbound
faxes, unlike 'archive').

I'm sure others can come up with more.

I'm sure some will say that these should really be C++ hooks to be called
from the Hylafax code.  That might be nice too, but I'd really prefer that
we provided something along the CGI lines.  CGI is very boring, but it's
very successful at being language neutral.  All it does is specify how
it's going to setup the environment, how parameters will be passed, and
how to send a response.

Does anyone else think this might a good approach to the "DB Integration"
issue?

Bill


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*