RE: flexfax: Design for a portable Java hylafax clients: i want your opinions, please!

["Bernd Proissl" <news@proissl.de>]

> -----Original Message-----
> From: Dmitry Bely [mailto:dbely@mail.ru]
> Sent: Friday, May 05, 2000 8:11 AM
> To: flexfax@sgi.com
> Cc: news@proissl.de
> Subject: Re: flexfax: Design for a portable Java hylafax clients: i want
> your opinions, please!
>
>
> "Bernd Proissl" <news@proissl.de> writes:
>
> > Hello to all hylafax users.
> >
> > I am currently developing a java hylfax client, there are some topics i
> > am thinking about, maybe you can give me your opinions:
>
> AFAIK the Java client is already created (by Suse people). They say it
> even works under Windows. Have you evaluated it? (unfortunately I still
> have not seen this piece of software). What is wrong with it?
> Which feature
> is missed?
I evaluated it some time ago, but it is too buggy/unstable to be used in
a business environment and furthermore it is too unfriendly to the end user.

AFAIR:
- you cannot view sent faxes. i think this is necessary (at least my
  client wants it.)
- The queues are displayed without any order. (like WHFC)
- jobs in the sendqueue and in the donequeue are not displayed in the same
  table (like WHFC)
- no support for things like redmon, cannot run in version a1, only supports
  version c (i appended this after b)
- overall appearance not suitable for a business environment.

Everybody sees every job. i think this is not good (for privacy reasons) and
even
not necessary and disturbing. My client only shows you your jobs. The jobs
from somebody
else are only displayed as long as they are in the out queue (togehter with
their priority
but without destination fax nr). So you can see how loaded the server is.
It appears as if you were using hylafax for your own.

i posted my design goals some months ago to the hylafax list. i have a
partially
working version of my client. you can control outgoing jobs on the server,
they are displayed better (i think) than in WHFC and SuSeFax.
It is not publically availabe yet. I somebody wants i can mail the
classes/sources.
I will set up a download location if there is the possibility to send faxes
also.

> > 1. is java 2 widely availabe on your (client) platforms?
> >    or is it supposed to become availbe in the near future?
> >
> > 2. What is your prefered procedure for sending a fax?
> >
> >    a1. redmon: capture the printout of an application on the client side
> >        and let the hylafax client process it: e.g. ask user for fax.nr.
> >        and the hand it to the hylafax server directly.
> >
> >        advantage: faster than a2
> >        disadvantage: - firewall must be opened for ports use by hfaxd
> >                      - if you want access for remote users you
> must open hfaxd ports
> >                        to the public.
>
> I think it is the only acceptable (working) solution.
>
> >    a2: same as a1, but client will send an eMail to some
> dedicated process on
> >        the server
> >
> >        advantage: - no firewall problem if eMail is allowed
> >                   - remote users can send faxes as if they
> where at the office
> >        disadvantage: slower than a1
>
> and
> - problems with attachments in the proprietary formats (MS Word etc.)
> - how to protect the service from unauthorised use? Anyone can send a
> message to your fax gate...
the handling from within the app is the same as with a1, all the document is
printed
to a virtual fax (including all application dependend documents)
redmon will transfer one created PS file to the hylfax client.
hylafax client asks for fax.nr. etc.
hylafax client sends fax.nr. etc as an eMail to the server, the PS file with
the
printout will be attached to this eMail.

yes, user authorisation will be more difficult in this scenario.



> >    b. printfax/repsond: capture the printout on the server
> side, make a "callback"
> >       to the client to get fax.nr. etc.
> >
> >       advantage: protocoll between client server can be easily
> adopted by other
> >                  developers
>
> Changing the protocol is the *disadvantage* :-)
>
> >       disadvantage: - another port must be opened for client
> server communications
>
> and the client software have to setup the "listening" service.
> But how this
> is supposed to work on X-terminals (Windows termitals etc.)? And
> what clear
> advantages we have (I don't see one)?
I implemented it once to get a self written app connected to hylafax
directly and easy.
It was more easy for me to send the fax.nr. and other data in one single
string
to printfax than deal with the hfaxd protocol.

The "listening" service can be done with java RMI and the rmid, especially
very easily
in java 2. Sun offers implementations for Solaris and Windows. rmid handles
incoming calls
of methods of local java objects. if the local object does not exist rmid
can startup a
JVM and instatiate the object transparently to the caller.

The necessity for java 2 is also in version a: redmon should not start up a
second
hylafax client if one is allready running. the hylafax client must register
an object
with rmid. this object will be activated by rmid from a process started by
redmon when
the user prints a fax.
The problem is that RMI only works "between" java objects. so redmon has to
start a JVM
with the only purpose to use RMI to "connect" to the hylafax client (which
may or may not run
allready in another JVM)

The object registered with rmid could also used from other java apps to fax.

Does anybody know another method besides java to use RMI?



  c.  redirect your application printout to a file on the client side
      (or maybe on the server side). the hylafax client then has to monitor
      the location for the file to appear and then start faxing.

      advantage:    - no printer port is needed on the client
                    - no admin priviliges needed if your app can print to a
PS file
      disadvantage: - JVM cannot be swapped out of memory because it
permanently has
                      to monitor the location. Maybe this is not a topic if
some
                      server side process monitors the location or if there
is
                      platform dependend code to monitor the location. e.g.
under NT
                      a Win32 app can register with NT to get messages if
there are changes
                      in the filesystem.


> > Currently it is usual that a client transfers a PS file to the
> server for sending.
>
> It's transparently converted to TIFF when sending.
>
> > Receiving faxes are stored in TIFF.
> > -> viewers for 2 different formats are needed on the client.
>
> Why? Are you going to view jobs in the send queue? Is it really needed?
yes.
> > Does anybody know a free printer driver which can produce TIFF
> files from
> > the printout of an application?
>
> I can speak of Windows world only. There is a number of shareware
> TIFF/bitmap printer drivers, but none are free (at least I failed to find
> one). E.g. see
>
http://www.slipstick.com/addins/fax.htm

> Can hylafax convert an arbitrary TIFF file to a TIFF file suitable for fax
> transmission?

Yes. You can submit TIFF file to Hylafax instead of PS. It will be
- sent "as is" if compression method & resolution are OK
(or)
- converted via tiffcp
(or)
- converted via tiff2ps | ps2fax (in harder cases)

Hope to hear from you soon,
Dmitry

Thanks!
Bernd