hmmm... just striping out the prefix wouldn't be a little naive?
what about a server providing bilbao:roads, madrid:roads and ny:roads ?
It could work as long as the namespace is properly preserved on each 
FeatureType, though, which I don't know if it's the case currently

Gabriel

On Saturday 28 October 2006 11:38, Andrea Aime wrote:
> David Zwiers ha scritto:
> > You could do this ... just beware of different conventions for FT names
> > (with / without prefix) for different server types. If you decide to
> > start stripping the prefixes in the datastore, you will need to store
> > the convention for the server somewhere (which andrea rejected ...).
>
> Did I? No, I did not expressed myself properly. That's exactly what I
> wanted to do, that is, keep inside the datastore a mapping between the
> name we use to communicate with the wfs server, and the name we show to
> the gt2 user.
>
> > You
> > are really trying to fix a bug in the specification, where the intended
> > use/format of the featuretype name was not clearly defined, and the
> > implementations did not come to a consistent convention.
>
> This is indeed something that should be worth pushing on OGC for a
> clarification in the standard.
>
> > How does Galdos' server cascade? How does Degree's Server cascade (open
> > source)? How do these servers (with mapserver) publish featureTypes? How
> > do these servers expect the FT to be named in a request?
>
> It may be interesting to check Degree... about Galdos, there is indeed
> a 30 days evaluation...
>
> > Answers to these questions will dictate how this needs to be fixed (if
> > at all).
> >
> > If you don't look after the convention issue (always an option), perhaps
> > the datastore should be renamed to GeoServerDataStore ... thus
> > advertising more acurately the intended use :). This option probably has
> > some speed inprovements availiable too ... but might open a can of worms
> > (filled with sockets?).
>
> Well, this allows me to voice something I had in the back of my mind...
> when uDig or whatever app based on gt2 communicates with geoserver, it
> would be nice to allow the usage of transport protocol more space
> efficient and less cpu intesinve than GML. It does not even need to be
> "our little secret", we can leverage stuff as java serialization (if
> only Feature was serializable, another big annoyance imho) or use
> protocols such as Hessian
> (http://www.caucho.com/resin-3.0/protocols/hessian.xtp),
> which is both binary, simple and language independent.
> It would still be WFS, just with a smarter encoding...
>
> Cheers
> Andrea Aime
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

-- 
Gabriel Roldán ([EMAIL PROTECTED])
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to