Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
RE: Design for a portable Java hylafax clients: i want your opinions, please!
> -----Original Message-----
> From: owner-flexfax@celestial.com [mailto:owner-flexfax@celestial.com]On
> Behalf Of Arne Hueggenberg
> Sent: Friday, May 05, 2000 1:00 AM
> To: flexfax@sgi.com
> Subject: Re: flexfax: Design for a portable Java hylafax clients: i want
> your opinions, please!
>
>
> Am Don, 04 Mai 2000 schrieben Sie:
> > 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:
> >
> > 1. is java 2 widely availabe on your (client) platforms?
> > or is it supposed to become availbe in the near future?
>
> yes and yes
>
> > 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.
>
> this would be my preferred mode, as it would be transparent for the user
> "simply print your doc to the "fax" :-)
the UI can be the same in both cases. java hylafax client could ask user for
fax.nr. etc
and then send mail to an SMTP server directly.
> as it is possible to restrict acess to ports by source ip i dont
> see that big a
> problem with this
what if your clients have dynamic IP adresses (DHCP or ISP for dial up)?
> > 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
>
> i dont like this due to the "dedicated process on the server, the
> vulnerability
> here is imo far greater than with a)
> another process wich can die etc.
> and remote users can use a) as if they were at the office too :-)
>
> > 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
> > disadvantage: - another port must be opened for client server
> > communications
>
> this would be another possibility, user transparent like a)
> but i dont really see an compelling argument for this, the
> current protocol is
> established, has mechanisms for transferring the relevant stuff,
> and is already
> implemented on the server side.
> Why do it again?
i forgot one:
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.
> > Receiving faxes are stored in TIFF.
> > -> viewers for 2 different formats are needed on the client.
> >
> > Does anybody know a free printer driver which can produce TIFF
> files from
> > the printout of an application?
> > Can hylafax convert an arbitrary TIFF file to a TIFF file
> suitable for fax
> > transmission?
> >
> > TIA for you opinions!
> >
> > Bernd
>
> Arne
>