You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <os...@dubioso.net> on 2007/07/23 21:47:44 UTC
TSCCM: status update
Hi all,
I've moved TSCCM into a separate package and started to factor
out some inner classes. As was to be expected, things get worse
before they can get better. Due to the private nested classes,
some of which are used C-struct-like, there were plenty of
direct attribute accesses spread in the code. I had to implement
accessors and partially increase visibility of attributes to
keep the stuff compiling. On the plus side, TSCCM itself is now
down to less than 1000 lines.
The next step is to factor out TSCCM.ConnectionPool. Once that
is done, I can start to clean up the mess of object relations,
visible attributes, public accessors, poorly chosen class names,
missing JavaDocs, and so on.
Still, prospects are bright. The code will become more open
though. There is little chance to prevent applications from
downcasting a connection wrapper and retrieving references to
classes which are not meant to be used by applications.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: TSCCM: status update
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2007-07-23 at 21:47 +0200, Roland Weber wrote:
> Hi all,
>
> I've moved TSCCM into a separate package and started to factor
> out some inner classes. As was to be expected, things get worse
> before they can get better. Due to the private nested classes,
> some of which are used C-struct-like, there were plenty of
> direct attribute accesses spread in the code. I had to implement
> accessors and partially increase visibility of attributes to
> keep the stuff compiling. On the plus side, TSCCM itself is now
> down to less than 1000 lines.
> The next step is to factor out TSCCM.ConnectionPool. Once that
> is done, I can start to clean up the mess of object relations,
> visible attributes, public accessors, poorly chosen class names,
> missing JavaDocs, and so on.
>
> Still, prospects are bright. The code will become more open
> though. There is little chance to prevent applications from
> downcasting a connection wrapper and retrieving references to
> classes which are not meant to be used by applications.
>
> cheers,
> Roland
>
At some point of time I would like to try to put together a connection
manager for NIO client connections. It would be really great if I could
re-use some classes from HttpConn. So, a more modular TSCCM is
definitely a very welcome improvement.
Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org