HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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



> > 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.
> 
> 	I feel, that the solution with samba may be work, but its not a
> very clean, nice solution. Why you may ask. I don't feel very comfortable
> with ps documents travelling in the network with the intention to send
> them as a fax without having an faxnumber attached to them. The risk to
> produce a mess with them is waiting in the corner.

This might be the case with the existing 'respond' program because it
is a one-way transmission.  What I'd like to see is an interactive
forms interpreter on the PC side so there would be a way to return
error messages (or success confirmation/job ids) from the unix-side
submission back to the sender.  Once the submission is complete
any later errors should be handled by email anyway.

> 	This approach may work without any problem with one User sending
> one or maybe ten faxes per day. If you have 50 Users a 10 Faxes per day
> you may get problems.

I've handled about that level with the older winflex client (actually
a newer version of the old winflex client that used to be at
morningstar.com and now seems to be living at
ftp://ftp.progressive-systems.com/pub/unsupported/windows/.  But, it
is more trouble than samba and not good for anything else.

> 	Hylafax is a complex technical system. Samba is also a complex
> technical system. If you join two technical systems together in the way 
> you do it with hylafax and samba the availability of the system drop 
> rapidly.

I don't agree with this.  If samba and hylafax are properly configured
they are both extremely reliable and you should have no new mysterious
failures by combining them, especially if your user namespace is
integrated so the server can email error notifications correctly.
What's more, there is no reason to think that a windows-printer-driver
solution would be any less complex or more reliable.  The only
missing piece is a handy way for the server to initiate an interactive
session that can persist through actual job submission.

Les Mikesell
  les@mcs.com




Project hosted by iFAX Solutions