[mapguide-internals] missing backward compatibilty of 2.1 server
API - feature or defect or magic?
UV
uvwild at gmail.com
Mon Apr 27 21:45:43 EDT 2009
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
>
More information about the mapguide-internals
mailing list