Jody Garnett a écrit :
> I understand what you are saying; the part I miss is this - why is the
> separation into two classes useful?
Just a separation of concern (if we can do that without duplicating code), and
also because I believe that for a significant fraction of applications (e.g.
desktop applications like uDig), buffering is the thing that matter since it is
the one that really impact performance in every case: mono-threads as well as
multi-threads.
> - createBackingStore - is used by all the createFoo(...) methods when
> they get a cache miss, the contract says a AuthorityFactory will be
> returned (I would like to enforce that as a DirectAuthorityFactory so we
> are explicit and do not get buffered on buffered action).
It can be a DirectAuthorityFactory, but also a AuthorityFactoryAdapter which
doesn't extends DirectAuthorityFactory...
> This contract is the same for both classes on the table; the code will
> be the same at the end of the day; are you wanting to change the
> configuration parameters of the pool? So BufferedAuthorityFactory only
> keeps one worker (ie a single BackingStore) and ThreadedAuthorityFactory
> has access to many?
* BufferedAuthorityFactory.getBackingStore() would just returns
the backing store specified at construction time; this is a
singleton. BufferedAuthorityFactory would not manage any ObjectPool.
DeferredAuthorityFactory would continue to extends BufferedAuthorityFactory
(we may deprecate this class anyway, so its fate is not really a concern).
* ThreadedAuthorityFactory add an ObjectPool and override the
getBackingStore() in order to returns a factory from this pool
rather than a factory specified at construction time.
So the code are not duplicated, and ThreadedAuthorityFactory really add
something new compared to BufferedAuthorityFactory.
> What use case is confused or gotten in the way of here? You seem to find
> the idea of buffering important ...
As said above, I would expect typical users to be more concerned about
buffering
than threading. A Threaded EPSG factory has values only if many thread are
going
to ask for many different CRS in same time - this is not typical for desktop
applications. It is more likely for server applications serving heteregenous
data.
> perhaps picturing
> BufferedAuthorityFactory as a simple wrapper around a backing store. I
> assure you it is far from a simple construct as the number of issues
> arising from the idea are many and far reaching...even when we restrict
> outself to one.
Yes a see BufferedAuthorityFactory as a simple wrapper around a single backing
store, and ThreadedAuthorityFactory as an extension for more advanced cases.
A simple wrapper as around a single backing store may be what some users want
when building a simple factory. For example a factory backed by WKT. Do we want
the whole WKT file to be loaded by each factory instance? With a simple wrapper
around a single backing store, the user is not faced to this issue. With
ThreadedAuthorityFactory, he need to think about that.
You seem to believe that "ThreadedAuthorityFactory extends
BufferedAuthorityFactory" will be a cause of difficulties or code
duplication...
I though that it would be something easy to do, separate concerns easily (with
real value added in ThreadedAuthorityFactory, like the ObjectPool which would
be
declared there) and provide something easier than ThreadedAuthorityFactory for
user who just want buffering...
If you feel that you don't have time to sort that out for now, please just
ignore. I can revisit later according what I will see in
ThreadedAuthorityFactory.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
