[mapguide-internals] missing backward compatibility of 2.1 serverAPI - feature or defect?

Fri Apr 24 05:48:24 EDT 2009

UV,
I believe many eyes are already open on this project and I do believe
that many good software engineering practice are included in it.

Before we talk about is it something wrong in architecture of MapGuide
or is it bug or is it missing feature, it would be necessary to
understand what is really happing in issue you are seeing.
Also, from what I understood email, your issue is that you think that
parameters in request are not backward compatible. At same time there is
"version" parameter, right ?
If that is case then it looks like the ones who created that part of
architecture of MG were thinking about versioning of requests.
It seems like your issue, if real, could be lack of functionality or
bug.

In any case, really understanding what is happing in the code in your
case is first thing to do.

Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Friday, April 24, 2009 2:48 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] missing backward compatibilty of 2.1
serverAPI - feature or defect?

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