[mapguide-internals] missing backward compatibilty of 2.1 server
API - feature or defect or magic?
Kenneth Skovhede, GEOGRAF A/S
ks at geograf.dk
Tue Apr 28 03:29:09 EDT 2009
I agree that, at the very least, the server should refuse all requests
from an incompatible webtier.
I don't entirely agree with "The problems that people have without the
in-depth knowledge dont get appreciated a lot.",
but I do agree that the overall entry barrier for MapGuide development
is a bit (too?) high.
The entry barrier for core developers is very high, and the architecture
document is a major step forward,
but it needs more diagrams like the one you added.
I have no comments on how to allow you to give "efficient contribution",
as I am not a core developer.
I hope someone else picks up on that.
I see your point about the VS versions, but I belive that IF there is a
VS2005 project file, people will expect that it works.
If no-one is maintaining it, it won't work for long.
So even if a person had a private automated build, they should update
the procedure, since
having a non-working build for VS2005 will be useless anyway.
Regards, Kenneth Skovhede, GEOGRAF A/S
UV skrev:
> ticket #972 describes my observations.
>
> Robustness:
> If there is an incompatibility with the versions the server has to
> detect this and should generate a specific HTTP response for this.
> This incompaibility between separate installations is an implicit
> configuration element which has a major frustration potential.
>
> Generally if it starts working it has to work all the way. That just a
> single operation is failing is bad system behaviour.
> That I have to know which versions are installed is magic as there is
> no easy way to find out.
> The server says its version in the help info but how do I find out the
> version of an installed webtier?
>
> I think there is quite a lot of magic involved in using this system.
> In my experience this is happening a lot when only experts are working
> on a system.
> The problems that people have without the in-depth knowledge dont get
> appreciated a lot.
>
> Thats where the continuous integration and some more robustness design
> principles come in (e.g.version checking of requests or sessions).
> Instead of writing the building and deployment details in a text file
> which is hard to maintain and use (or the wiki where its hard to find)
> they should go into the configuration within the repository.
> If the reference is an external builds system every detail has to be
> part of the configuration. Thats the beauty of CI.
>
> Again I am really willing to sort such things out because I have the
> experiecne and had enough recent frustration with this to be
> motivated enough.
> But the process has to improve. Currently I cannot do any efficient
> contribution.
> Also I am missing phone conferences. Thats how I am used to sort out
> issues more efficiently in my previous international projects.
>
>
> Kenneth Skovhede, GEOGRAF A/S wrote:
>> As I see it, there are three things here:
>>
>> 1) You get a bad error message, please report a bug ticket for that
>>
>> 2) If that is indeed what happens, it is a bug, and should be
>> reported with a ticket.
>> To clairify the exact problem, can you post a full request string
>> that fails and one that does not?
>> As I see it, the "DESCRIBESCHEMA" operation works as I would expect
>> in both version 2.0.2 and 2.1.
>> If the problem is with a Studio request, try turning on request
>> logging in IIS or Apache, and send the requests,
>> so I can replicate the request.
>>
>> 3) You feel that the versioning is bad.
>> If issue 2 is a bug, your comment is not entirely valid: The MapGuide
>> project does adhere to version standards.
>> The Maestro application supports version 1.2 up to 2.1, and I have
>> only added functions as they became avalible,
>> I never had to add a tweak to be backwards compatible.
>>
>> As for the VS2005 and VS2008, I feel that the moves was valid, and
>> that it would be a very large task to
>> support two seperate build systems in future versions, and greatly
>> increase the possibility that bugs occured due to this.
>> It is unfortunate that VS2005 and VS2008 dll's won't play nice
>> together, but I still think that the upgrade was
>> the right thing to do.
> VS2005 - VS2008
>
> I understand your points and I agree that maintaining those parallel
> build structures is not a good option.
> However, creating such a parallel tree of projects and solution files
> in the first place is not so much work. This is just a bit more
> detailed configuration management. We talk about a few hours. I have
> done such things many times.
> Also there are so many examples in the Oem tree where this is done
> exactly like this in a very clean way.
> My point is that a previously working 2005 version would be probably
> still useful for quite some time after creating the VS2008 tree.
>
> So we are comparing the time saving of simply converting the old 2005
> projects instead of duplicating the tree to the advantage of being
> able to build the system for maybe a year or so still with VS2005.
> Only this I am questioning.
>
> So the decision to go for 2008 is undisputed ..... the destructive way
> of implementing it, however is in my experience questionable
> in particular in an open source environment where people might not
> have the latest software releases at hand. This is different from an
> ongoing support of the old build.... it just is about: dont break what
> was working before.
>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>
>>
>>
>> UV skrev:
>>> OK I think I am on case 3.
>>>
>>> 1. But still the system response we get from this is badly
>>> misleading. (made me think my library is broken)
>>>
>>> 2. And I still dont understand why the operation is failing instead
>>> of a continued support of the old version of the request
>>> and a new support of the new version? I thought thats why there are
>>> schema versions in the server.....
>>> And please prove me wrong but if the server recognizes an error it
>>> could also recognize the previous API format and process the request
>>> correctly?
>>>
>>> This is the same odd approach as in removing the VS2005 support and
>>> replacing VS2008 support as opposed to adding it!
>>> In large complex software systems you need to have a really good
>>> reason to break backwards compatibility.
>>> Please tell me this reason!! So far it has been.... because we did
>>> it like this.... sorry but thats still not good practise.
>>>
>>> Generally the whole versioning approach in this project is quite
>>> fragile.... and it seems to be considered as acceptable practise
>>> to carry on like this. Again why?
>>>
>>> Example:
>>> If we are looking at an upscaled deployment scenario in a server
>>> farm with dedicated web servers nodes and mapguide nodes
>>> this versioning scenarios is making deployment and upgrading a
>>> production system very difficult.
>>> Unless single node deployments are the clear architecture goal this
>>> is bad practise....
>>>
>>> Please guys. lets think about all these other cases.... its really
>>> not so much extra work to follow the principles that make it so much
>>> more robust.
>>> and robustness is a system property this project cannot claim as yet..
>>>
>>> I really dont want to moan here..... we are not going to change
>>> things from one day to another. I want to help to open the eyes and
>>> incorporate valuable software engineering principles to the benefit
>>> of everyone.... If it does not happen now... so hopefully next time!
>>>
>>> UV
>>>
>>> Steve Dang wrote:
>>>> Some notes about MG backward/forward compatibilities:
>>>>
>>>> 1. Old/new web extensions and servers must not be mixed.
>>>> 2. Old clients should work with old/new web extensions and servers.
>>>> 3. New clients will not (always) work with old web extensions and
>>>> servers.
>>>>
>>>> The problem that UV ran into is probably related to #3.
>>>>
>>>> Steve.
>>>>
>>>> -----Original Message-----
>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
>>>> Tom Fukushima
>>>> Sent: Thursday, April 23, 2009 3:51 PM
>>>> To: MapGuide Internals Mail List
>>>> Subject: RE: [mapguide-internals] missing backward compatibilty of
>>>> 2.1 server API - feature or defect?
>>>>
>>>> Hi,
>>>>
>>>> According to the RFC, everything done in there is backwards
>>>> compatible. What's going on? Steve, do you understand the problem
>>>> that UV is running into?
>>>>
>>>> Tom
>>>>
>>>> -----Original Message-----
>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
>>>> Walt Welton-Lair
>>>> Sent: Thursday, April 23, 2009 10:05 AM
>>>> To: MapGuide Internals Mail List
>>>> Subject: RE: [mapguide-internals] missing backward compatibilty of
>>>> 2.1 server API - feature or defect?
>>>>
>>>> It was changed as part of RFC 53. I agree - the HTTP request
>>>> version should have been incremented for the updated APIs.
>>>>
>>>> -----Original Message-----
>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
>>>> Sent: Thursday, April 23, 2009 11:55 AM
>>>> To: MapGuide Internals Mail List
>>>> Subject: Re: [mapguide-internals] missing backward compatibilty of
>>>> 2.1 server API - feature or defect?
>>>>
>>>> DESCRIBEFEATURESCHEMA&VERSION=1.0.0
>>>> RESOURCEID=.....
>>>>
>>>> and the parameter count of mapguide studio 2.0.0.3202 is not
>>>> compatible to 2.0.2
>>>> using 2 instead 3 parms i think.
>>>>
>>>> supposedly the maestro client has been updated....
>>>>
>>>> I am simply questioning why to break it in the first place......
>>>> I believe breaking compatibility in the API between successive
>>>> versions is bad practise......
>>>>
>>>> Jason Birch wrote:
>>>>
>>>>> Do you know which specific API call was changed, causing the
>>>>> exception?
>>>>>
>>>>> -----Original Message-----
>>>>> From: UV
>>>>> Sent: April-23-09 8:03 AM
>>>>> To: MapGuide Internals Mail List
>>>>> Subject: [mapguide-internals] missing backward compatibilty of 2.1
>>>>> server API - feature or defect?
>>>>>
>>>>> A recent attempt to verify the map structures used for my test
>>>>> case using Mapguide Studio
>>>>> an access to a data resource from within a layer triggered an
>>>>> exception in the server.
>>>>> (unable to process operation)(Resource ID does not refer to a
>>>>> valid feature source)
>>>>>
>>>>> This is due to a changed parameter count in the request package.
>>>>> _______________________________________________
>>>>> mapguide-internals mailing list
>>>>> mapguide-internals at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>
>>>>
>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
More information about the mapguide-internals
mailing list