Re: [udig-devel] Plea to avoid workarounds for broken servers

[James Macgill <jmacgill@xxxxxxxxx>]

See my comments in the IRC log that will be posted shortly.  I all but
come round to this way of thinking.  My only holdovers remain clear
seperation of code for parsing working servers from code to deal with
broken servers and an abbility to display a detailed error/warning
message that would give the implementer of a server a good chance of
knowing exactly why they were off spec.

James


On Mon, 17 Jan 2005 13:03:35 -0800, Paul Ramsey <pramsey@xxxxxxxxxxxxxxx> wrote:
> Sorry, we are not Wal-Mart. The reaction to uDig failing to work with a
> server will be "uDig is broken" not "the server is broken". We will
> report errors we find in servers to the authors, particularly early on
> pre-release, but making things work seamlessly is the goal, and if that
> means we have to load up some other people's problems on our shoulders
> on occasion, so be it.
> 
> In addition, supporting "non-standard" things like ArcXML is on my
> agenda. I want an integration tool, and am not going to be doctrinaire
> about how that is accomplished.  There's data in ArcIMS servers I want
> to see, there's data in broken WMS servers I want to see.
> 
> P.
> 
> On Monday, January 17, 2005, at 11:59 AM, James Macgill wrote:
> 
> > I know its a very hard decision to make and it is hard to be the group
> > that makes a stand, but I would hate to see the WMS and WFS specs
> > going the way of HTML.
> >
> > The major players Netscape and IE were so forgiving with html markup
> > that it almost stopped being a standard and novice page writers and
> > tool developers thought they were writing valid code because it always
> > seemed to work.  (<b><i>bold italic</b></i> anyone?)
> >
> > The seperation makes some sense, though it might well lead to a fork
> > of the data store modules.  How, for example, would you work around a
> > broken 1.3.0 WMS that was using x and y instead of i and j for pixel
> > coordinates without modifying the code in geotools?
> >
> > I feel that the workarounds would make the code harder to maintain and
> > would further remove pressure on server developers to fix their code.
> >
> > That said, I can appricate that limiting what a user can do is not
> > something you may want to contemplate, in which case can I at least
> > ask for a strong error warning box so that the user knows they are
> > working with a broken server.
> >
> > James
> >
> > On Mon, 17 Jan 2005 11:19:31 -0800, Richard Gould
> > <rgould@xxxxxxxxxxxxxxx> wrote:
> >> Hi James,
> >>
> >>> I'd just like to make a plea that no-one adds workarounds for broken
> >>> servers into the codebase, (I have no indication that anyone has done
> >>> this yet, but I just want to be sure no-one is even slightly
> >>> tempted!)
> >>>
> >>>
> >> Too late. David's XML implementation allows quite a large amount of
> >> flexibility on the parsing end, allowing quite a few misbehaving
> >> servers
> >> to be read properly. I have already added in some fixes that allow us
> >> to
> >> parse non-standards compliant servers (and they are not hacks).
> >>
> >>> A broken server is just that, and any attempt to support or work
> >>> round
> >>> servers that are off spec will lead to a slow but painfull death for
> >>> interoprability as a whole.  It is tempting to want to give the 'best
> >>> user experience' by letting our users see the content of broken
> >>> servers but if everyone did that we might as well not have standards.
> >>>
> >>>
> >> My initial instinct is to disagree with you on this one, but I am
> >> definately willing to heed your wisdom, as you definately have more
> >> experience with this sort of thing compared to myself. It seems to me
> >> that the value of being able to parse nearly every single server out
> >> there is more than strictly enforcing the standards. If someone wants
> >> to
> >> use the code to communicate with a specific server they have in mind,
> >> they might be turned away if they find we cannot parse it. It is
> >> probably less work on their behalf to find a client that *does* parse
> >> it
> >> than contacting the administrator of the server and informing them of
> >> their standards deviance.
> >>
> >> It also doesn't mix well with uDig's goals of as much interoperability
> >> as possible. A possible fix for this would be to separate the WMS
> >> plugin
> >> into a strictly standards compliant section (GeoTools) and a more
> >> relaxed version (uDig).
> >>
> >> Richard
> >>
> > _______________________________________________
> > User-friendly Desktop Internet GIS (uDig)
> > http://udig.refractions.net
> > http://lists.refractions.net/mailman/listinfo/udig-devel
> >
>       Paul Ramsey
>       Refractions Research
>       Email: pramsey@xxxxxxxxxxxxxxx
>       Phone: (250) 885-0632
> 
>