I cannot apply your patches. All 3 files report errors when applying with
patch -p0 < patchfile
I am up to date with 2.5.x repository
No idea, I think you are sitting in front of an M$ box, I am working on a
linux box. Converting with dos2unix does not help either.
Can you try it agein after an "svn up" on 2.5.x or send me the java files.
thanks
Jody Garnett writes:
> 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
