Just to follow up - Christian and I sorted out some things over IRC;
and he is reviewing a patch right now.
Jody
On Thu, May 14, 2009 at 10:52 PM, Jody Garnett <jody.garn...@gmail.com> wrote:
> Sorry my previous reply fell of the list ... here is a proposal for a
> "refreshed" Repository interface:
>
> public interface Repository {
> /**
> * Search for the DataAccess (or DataStore) providing access
> * to the indicated typeName.
> * <p>
> * This lookup method is not namespace aware; and will find the first
> * possible match.
> * <p>
> * @param name Name of the DataStore to retrieve
> * @return DataStore
> */
> DataAccess<?,?> access( String typeName );
> /**
> * Search for the DataAccess (or DataStore) providing access
> * to the indicated typeName.
> *
> * @param Name The typeName (namespace and name) to search for
> * @return DataAccess api providing access to the
> indicatedTypeName (or null if not found)
> */
> DataAccess<?,?> access( Name name );
> }
>
> A couple changes from yours:
> - DataAccess is returned rather than DataStore
> - namespace is part of Name
>
> I find this a little weak in that you cannot "browse" the contents of
> the Registery; however since we do not have a need for that - only
> look up - I think we are fine.
>
> I find it really stange that you are lookin up DataStore here; by the
> typeName the DataStore produces. A code example would end up being.
>
> Name typeName = new NameImpl( namespace, name );
> DataStore<?,?> data = (DataStore<?,?>) registery.access( typeName );
> FeatureSource<?,?> source = data.getFeatureSource( typeName );
>
> I would find it easier with a single registery.source( typeName )
> method; but whatever. I might also suggest a dataStore method to avoid
> the cast to DataStore.
>
> So how about it; if I make this modification can we update your code
> (and implementation) to make use of it?
>
> Jody
>
> On Thu, May 14, 2009 at 10:33 PM, Jody Garnett <jody.garn...@gmail.com> wrote:
>>> Jody I took a deeper look to Catalog interface and I got dazed and confused.
>>
>> Not the catalog interface the simple repository interface ...
>> interface {
>> Map getDataStores();
>> SortedMap getFeatureSources();
>> Set getPrefixes();
>> boolean lockExists(String lockId)
>> boolean lockRefresh(String lockId, Transaction)
>> boolean lockRelease(String lockId, Transaction)
>> source source(String dataStoreId, String typeName )
>> }
>>
>> And you have:
>>
>> public interface DataStoreLookup {
>> public void initialize(Object source);
>> public DataStore getDataStoreFor(String name);
>> public DataStore getDataStoreFor(String namespace, String name);
>> }
>>
>> So one is working with FeatureSource and the other is working with
>> DataStore; incidentally how do you look up a datastore for a
>> namespace/name ? does that not indentify a single feature type? I also
>> do not know what your initialize( source ) method is for ...
>>
>>> Again I agree on having a central repository interface but a redesign is
>>> not a matter of adding some methods.
>>
>>> Some thoughts
>>> 1) I am missing the clean concept of namespace handling
>>
>> Then we add it; right now the api documents something stupid - a
>> datastore id since that is what geoserver had when it was written.
>> Which each have a lookup method that takes two strings - both are
>> supposed to be a simple front end to the geoserver catalog so they
>> probably end up acting the same.
>>
>>> 2) It must be possible to write a Repository implementation acting as
>>> adapter for the geoserver catalog (supporting the workspace concept, which I
>>> think we could handle with 1). The same must be possibile for UDIG. The
>>> interface implementation must be configurable externally, we need something
>>> like a "RepositoryFactory"
>>
>> Ignore uDig for a moment; focus on what geoServer is doing; I can make
>> udig work later.
>>
>> I did not follow you their; you probably intend to pass in this
>> repository as a connection parameter to your pregeneralized datastore?
>> Something either application can do.
>>
>>> 3) Unlucky naming of methods, "source" as an example. You must look at the
>>> source code to have an idea what this method is doing. Missing methods, how
>>> to get a datastore with his name and namespace ?
>>
>> You are focused on name and namespace; that is fine. Source is the
>> super type of FeatureSource (something gabriel did). I am not sure if
>> your datastore is generic enough to work on Source (does it assume
>> simple features or not?).
>>
>>> 4) No idea about the locking methods, I think nobody calls them, and btw, I
>>> would delegate the locking to an
>>> external locking manager. And why should a repository do locking at all ?
>>
>> We can remove them; the reason locking had the responsibility was
>> because it was the only interface that "knows" all the datastores and
>> thus can perform cross datastore operations (such as locking).
>>
>>> So, I think we would a least need
>>> RepositoryInterface
>>> RepositoryFactory
>>
>> I think we can skip the factory on this one; we are not creating a
>> generic Repository; we are being passed in an adapter to the geoserver
>> catalog.
>>
>>> RepositoryImpl for geotools
>>
>> This is pretty simple to write; just store the datastores in a map.
>>
>>> RepositoryImpl for geoserver
>>> RepositoryImpl for udig ?
>>
>> These other two seem okay.
>>
>>> This would be a real improvement but it would block me for weeks.
>>
>> I do not want to introduce duplicate api for the same function; would
>> you like to have a breakout IRC session and fix the repository
>> interface to match your datastore finder? You do have to explain your
>> two part namespace / name lookup - looking up a DataStore for me;
>> right now that makes little sense to me.
>>
>>> As a proposal, I would like to continue with the DataStoreLookup and mark it
>>> depricated as soon we have implemented a cleanrepository concept.
>>> christian
>>
>> I am interested in going the other direction; replacing the Repository
>> interface methods with what you have in DataSource lookup. Part of the
>> difficulty here is that your module "introduces" public api - not
>> simply implementing the DataStoreFactory (which can be dropped into
>> any app; but instead asks to go out into the app that is hosting it
>> and look up other datastores).
>>
>> Jody
>>
>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
