[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Plea to avoid workarounds for broken servers
|
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
