[mapguide-internals] missing backward compatibilty of 2.1 server API - feature or defect?

Sat Apr 25 03:23:19 EDT 2009

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.

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