feedback on possible mapserver enhancements

[Steve Lime]

By "already been written too" I was thinking "then why bother"...

>>> On 2/5/2008 at 3:27 PM, in message <20080205212716.GB7058 at alta.metacarta.com>,
Christopher Schmidt <crschmidt at metacarta.com> wrote:
> On Tue, Feb 05, 2008 at 02:30:12PM -0600, Steve Lime wrote:
>> Maybe folks just want some FeatureServer-like functionality... (yes, I know 
> that's already been written too)
> 
> If they just want FeatureServer-like functionality, it's likely that
> they should be looking at something like-FeatureServer.
> 
> Is there a cost to installing FeatureServer? Yes. 
> Is there a cost to developing Feature Updating Services in MapServer?
> Absolutely.
> 
> I don't think we have a strong enough idea of what users actually want
> from updating features in MapServer to understand whether the total cost
> on users of installing FeatureServer is more or less expensive than the
> total costs of modifying MapServer to do it.
> 
> I think that, based on my (admittedly limited) understanding of
> MapServer's internals, developing Feature updating support is unlikely
> to be a seamless integration. The reason for this is that MapServer
> supports multiple different vector providers (as I understand it): there
> is 'built in' support for Shapefiles and PostGIS, as well as support for
> 'external' vectors via OGR. I believe that MapServer does have an
> internal representation of features -- but how do you take thosoe
> features and update a PostGIS layer where the CONNECTION string is based
> on a subselect? Can you really know that you have enough information to
> update the datasource without it being specifically configured for
> updates... and if the user has to learn a lot to configure MapServer to
> do this updating, is that really lower cost than installing
> FeatureServer (which really only requires Python)?
> 
> The cost of building something like FeatureServer in C is high -- this
> is why it's written in Python in the first place. Reading in GML --
> especially when people expect to be able to throw random crap at you --
> is possibly hard, and ensuring that it fits a schema may be harder, etc.
> 
> FeatureServer has survived through this becasue:
>  1. It's specialized. Since the entire framework is written with the
>     challenges of the problem in mind, it's well-suited to the solving
>     the problem: there is nothing like a subselect-query from
>     FeatureServer, because that's not something you can update. 
>  
>  2. It's easy to hack to bits when something doesn't work: Python is way
>     more hackable than C, so I've been able to hack it apart
>     significantly in order to change support for just the PostGIS
>     provider (for example).
> 
>  3. The abstraction barrier between datasources and output is well defined.
>      Everything is super-seperated, and the end result is that
>      DataSources have no knowledge of the formats that features are in.
>      This is a problem for implementing WFS-T, for example, because
>      information in WFS-T isn't passed along in the feature model of
>      FeatureServer (because it's solving a different problem).
> 
> All these things allow FeatureServer to be much more quick to respond to
> problems with specific setups -- and also lead to a situation where
> MapServer is not (based on my understanding) in a suitable flexible
> position to be able to implement the types of actions that are being
> discussed.
> 
> I'm interested in understanding why FeatureServer is so much more
> difficult than MapServer to get installed: It seems to me like it would
> be easier to set up FeatureServer in almost any environment than
> MapServer would be, but maybe I'm not understanding something. Perhaps
> attacking that problem, if it exists, would reduce the feeling of a need
> for FeatureServer-like access to MapServer. 
> 
> FeatureServer is about Serving Features. MapServer is about serving
> *maps*, and anything that isn't about *serving maps* should perhaps be
> considered strongly before too many people get in a rush to change the
> situation. There's a lot of differences between something like
> FeatureServer and MapServer which make the fundamental development cost
> seriously different between the two libraries, and it seems to me that
> perhaps there are other problems that it would make more sense to solve
> in MapServer while addressing the need to make select/update/modify/delete
> of features more easy seperately. 
> 
> Regards,