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

[Dmitry Bely <dbely@mail.ru>]

"Bernd Proissl" <news@proissl.de> writes:

> > > 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)

For WHFC it can be partially solved by changing /usr/local/lib/hfaxd.conf

> - 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.

Fine. I really miss this feature in WHFC (and many other but its
development seems to be stopped).

> 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.

So you are going to use E-mail only as a transport layer to deliver jobs to
the server? I think this is not adequate decision. Use Hylafax protocol
instead (a1). It is not so complicated as seems at the first sight. You
will need it in any case, because there no other way to remotely manage
Hylafax's operation.

> 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.

Almost impossible. And why to duplicate features what already implemented
in the hfaxd server protocol? And what will you do if a user send a message
to your fax gate with Word attachment not using your client software?

> > >    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.

Again, it is not so complex. Look into sendfax's sources: it submits jobs
via hfaxd protocol (sendfax/sendfax.* util/SendFaxClient.*). I also think
that you may ask WHFC author for help/example sources.

> 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?

I hope you will change your mind and concentrate on (a1)
development :-) Believe me, there is no need in (b) implementation.

>   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.

I don't understand what you mean. What is the difference between (a1)
and (c)? You are going to implement port monitor functionality yourself?

>       advantage:    - no printer port is needed on the client

?? IMHO in Windows any printer driver has an assotiated printer port. You
cannot change this. And why?

>                     - no admin priviliges needed if your app can print to PS file

Which admin privileges are needed for (a1)?

>       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.

Hope to hear from you soon,
Dmitry