On Mon, Mar 5, 2012 at 4:10 AM, Gabriel Roldan <[email protected]> wrote: > On Sun, Mar 4, 2012 at 5:28 AM, Andrea Aime > <[email protected]> wrote: >> On Sun, Mar 4, 2012 at 1:04 AM, Gabriel Roldan <[email protected]> wrote: >>> FWIW, imho it should be possible to declare this and other service metadata >>> on a per-FeatureType basis. >>> I'm not sure, but it seems that the implementations that drive the spec work >>> a lot different than GeoServer, like in if they work against a single >>> "backend" hence having a fixed set of capabilities for all types. >>> Hence, in order not to sound like unneeded critic, I wonder what should I do > > edit: "...what should _we_ do..." > >>> as a community to help drive future versions of the spec. >> >> I always thought one of the reasons for WFS to exist was actually to hide >> the fact the different feature types might be coming from different sources, >> and make everything look uniform. > > Nobody is saying the opposite. I may be missing something, but how do > you distinguish an editable feature type from a read only one off the > capabilities document?
That would need extensions to the current protocol of course. Everything I suggested below would in fact, I should have been more explicit. >> At the same time I agree the above vision has a quite the cost, in various >> ways: >> - bringing up less capable data sources to have the same features as the >> most capable ones is costly >> - working against some emulated, non native, feature (e.g., sorting >> over large data set) >> has a runtime cost. >> >> Thinking about the runtime costs, there are issue that extend beyond the >> data source differences, given a single feature type some fields are indexed, >> some are not, it's not the first time I hear people asking for ways to >> limit acceptable >> WFS filters so that they include at least one condition on a indexed field to >> avoid killing the database on a long and hard sequential scan. >> The same could be applied to styles posted along with a GetMap request (SLD >> 1.0 >> WMS extensions, &sld, &sld_body and so on) >> Something similar could be said about WFS-T, maybe you have some editable >> fields, and some others that are compute on the fly and are thus non >> editable. >> >> Of course being able to specify all of the above on a per type basis would >> make >> clients harder to build. Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
