From: Christian Westermann <chrigu@kl...> - 2001-09-20 06:40:22
i have some minor questions to the assigned task which is the implementation
of ftp in the client side.
should the client work as a full featured ftp client or should the client
work as a "test" client, providing some test methods able to do e.g. some
statictics and so on?
in your design the protocol clients should extend from
AbstractProtocol.java. i'm not sure if every method in AbstractProtocol.java
is also used in an ftp client. AbstractProtocol.java looks to me more like
an upper class for an http client, but maybe i'm wrong here.
From: Artur Hefczyc <wislaj23@wp...> - 2001-09-20 07:09:16
> should the client work as a full featured ftp client or should the client
> work as a "test" client, providing some test methods able to do e.g. some
> statictics and so on?
I wish our implementations of internet protocols will be full implementation
of protocols specification.
And over our protocols implementation we can build many different web clients.
Some of them could be simple test clients and other could be full web clients
ftp, http, nntp for example.
I hope that in future our protocols implementation will very good and other developers
from other java projects will be using our protocols implementation in their
applications which could be different kind of application than ours..
Of course we can first create simple protocols implementation which can do only
subset of particular specification and later we can add more features.
I would like to have something working as soon as possible even if it can't do many
For example if we could have in the begining protocols implementation which could
only detect web server type I would be satisfied in it, becouse I could create client
gather statistical info from the internet what web servers are common used in the
> in your design the protocol clients should extend from
> AbstractProtocol.java. i'm not sure if every method in AbstractProtocol.java
> is also used in an ftp client. AbstractProtocol.java looks to me more like
> an upper class for an http client, but maybe i'm wrong here.
Yes you are right.Not all methods in AbstractProtocol are common for all protocols.
But my idea is to have one class wich could be bridge for clients between urls and
content. I mean that some client have URI to some web resource.
If he could use one class (AbstractProtocol) for example he don't need to know
what protocol is used to reach this resource. AbstractProtocol can hide protocol
Notice that if we will create some test tool which get set of urls. For example
10 000 usrls to test if they point to correct location. Some of them could be
HTTP urls other FTP and so on. Our tool shouldn't know how to use
particular protocol. It should be able to use all urls the same way.
If it use AbstractProtocol every url content can be downloaded the same way,
every web server could be detected the same way, every content-type
could be detected also the same way, and so on.
Of course every protocol have specific functionality which we can add to
AbstractProtocol or not.
So, for now it seems to me that all protocols implementations should extend
AbstractProtocol and we should design this class to be usefull for all protocols
If you have any sugestions please send them.