Re: flexfax: Hylafax future (*not* on NT, please!)

[Leslie Mikesell <les@Mcs.Net>]

> On Wed, 17 Sep 1997, Evan Leibovitch wrote:
> 
> > HylaFAX operation is the antithesis of the NT way of doing things. 
> > Command-line administration, chains of compact tools rather than
> > monolythic programs, no fancy GUIs, documentation in FAQs and manpages --
> > all classic Unix methods. How much work would be required to make this
> > usable in the NT world?
> 
> 	Hm. There is something other... There are fax servers for Windows
> NT, and they are not soooo bad. Why should we produce another one...

How about so people who are used to setting up HylaFAX can continue to
do it the same way when there isn't a suitable unix driver for the
serial port card they want to use, or there are other reasons to be
running NT on the box?

> 	The trick with Hylafax is, that it fits more or less perfectly in
> Unix systems. This is the real value of Hylafax - not the pure
> functionality of the package. If you are using a linux or unix box as a mail 
> server, as a web server or whatever - you get also a fax server.

I'm not sure I understand how unix is unique in this respect.  The HylaFAX
client/server protocol is not exactly like anything else. 

> With a
> port to NT, Hylafax can only loose. The commercial packages are all
> colorfull blinking beasts with dancing wizards and what ever. I think it
> isn't worth to give them a competition...

Having choices is always worthwhile, assuming someone is willing and able
to do the port.  People who run servers understand that flashy interactive
interfaces have nothing to do with the underlying functionality and often
get in the way.

> 	I think, the greatest point and problem of hylafax is the lack of
> good client software for this. I made several attempts to create a windows 
> client - I gave up every time. I also made a little bit reverse
> engeneering of other fax packages for windows - they are hooking in the
> windows printer driver system and do all other jobs by there own. Ok, WHFC
> is a good work and the samba system is a good workaround - but both of
> them have their specific problems.

Your earlier point about 'fitting' into a system indicates that you should
make use of the best existing techniques to get the job done.  Samba does
a good job of delivering postscript from a windows printer driver to
the server.  The missing piece is an interactive dialog box that is
_controlled_by_the_server_.  This is something that could be used in many
more applications and would complete the circle for HylaFax.  Respond
does it well enough to work for HylaFax, but what we really need is
an HTML forms interpreter (or some reasonable subset) that could be
poped up on demand by the remote server.  This could be used by any
server-based application that needed fill-in-the-form response(s) from
a user.

Les Mikesell
  les@mcs.com