From: Gabriel <gr...@ax...> - 2006-10-28 10:36:53
|
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=20 =46eatureType, 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=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel =2D-=20 Gabriel Rold=E1n (gr...@ax...) Axios Engineering (http://www.axios.es) Tel. +34 944 41 63 84 =46ax. +34 944 41 64 90 |