Failing operation when accessing 2.1 server with 2.0 client

[uvlite]

config: 2.1 server (revision 3838) 2.0.2 webtier (build 3011) Autodesk Mapguide Studio 2.0.0.3202

Open any layer!!! Operation to access featuresource fails with HTTP/1.1 559 MgInvalidStreamHeaderException

GET /mapguide/mapagent/mapagent.fcgi?OPERATION=DESCRIBEFEATURESCHEMA&VERSION=1.0.0&SESSION=f75c4b84-1559-102c-8000-00b0c201ec7a_en_7F0000010AFC0AFB0AFA&LOCALE=en&RESOURCEID=Library%3a%2f%2fCDM%2fTRANSPORT%2fSDF%2faug+06-BARRIERPOINTS.FeatureSource HTTP/1.1

....any layer and any feature source in this configuration.

Reassigning featuresource is not working either.

Confusing error message in MapGuide Studio: Resource ID does not refer to a valid feature source.

Debugging shows that the number of parameters for the DESCRIBEFEATURESCHEMA is wrong.

[uvlite]

config:
2.1 server (revision 3838)
2.0.2 webtier (build 3011)
Autodesk Mapguide Studio 2.0.0.3202

Open any layer!!! Operation to access featuresource fails with
HTTP/1.1 559 MgInvalidStreamHeaderException?

GET /mapguide/mapagent/mapagent.fcgi?OPERATION=DESCRIBEFEATURESCHEMA&VERSION=1.0.0&SESSION=f75c4b84-1559-102c-8000-00b0c201ec7a_en_7F0000010AFC0AFB0AFA&LOCALE=en&RESOURCEID=Library%3a%2f%2fCDM%2fTRANSPORT%2fSDF%2faug+06-BARRIERPOINTS.FeatureSource? HTTP/1.1

....any layer and any feature source in this configuration.

Reassigning featuresource is not working either.

Confusing error message in MapGuide Studio: Resource ID does not refer to a valid feature source.

Debugging shows that the number of parameters for the DESCRIBEFEATURESCHEMA is wrong.

[ksgeograf]

The problem here is not the client, but the mixing of webtier and server versions. You cannot mix the two. They are in seperate MSI packages because you can install them on different machines if you like.

Studio has no effect on this.

The problem occurs because the binary objects only exist in the current version, and the binary objects are serialized/deserialized using their current format. If you send a 2.0 object into the 2.1 server, there is no logical way of handling the missing fields, especially if the object is later sent back from 2.1 to 2.0.

The current serialize/deserialize methods works by manually crafted code in each class. This gives the greates flexibility but also removes any chance that this could be automated, or centrally handle version differences. This means that the binary objects are heavily tied to the version being used. Managing multiple binary versions would have a rather large overhead. To obtain version compatibility, you can rely on the http interface, like Maestro and Studio does.

If you update the webtier you should find that Studio works as expected, as it is using the http interface, which correctly handles the different versions.

[uvlite]

I see. But the simple statement that we cannot mix the two says it all.

This is a good example of implicit expert knowledge which is required to use this system.

Robust design would require: The system has to know what its dealing with.

The fact that I can have different versions running on different nodes and no part of the systen notices the problem is a minor but still a defect from my understanding of system design.

There is a simple solution.

Many other systems use a unique identifier to identify serialized objects. In my experience (taking into account a limited insight into details by many engineers involved in using and handling such a system) this leads to problems as the one I have described.

The most simple way to handle this is to exchange version numbers in the create session operation.

[jng]

Solving this problem requires a more detailed discussion on internals with possibly an RFC detailing the solution in greater detail