Improve load time for Runtime map Initialization

[ksgeograf]

When the runtime map is created, the server issues "DescribeSchema" for all layers in the map, regardless of the maps current visiblity status. This causes very slow loads if one of the layers is a WFS source, in extreme cases the map does not load at all, but times out.

I belive the only reason for the initial call to "DescribeSchema" is to populate the "IDs" array in the runtime layer.

The code should be updated so that the ID's are initally set to null for all layers, except the visible ones. Once the layer is set to visible, the code should test for the null case and call "DescribeSchema" if needed. In all case the "IDs" array should be set to a zero length array after the call, to avoid extra calls later on.

This will speed up map creation, and reduce the stall to happen on a single layer, which is much easier to track down.

I'm unsure if the ID's are required for anything but selection (tooltips perhaps?). If not, the change should defer the call to "DescribeSchema" until the layer is both visible and selectable.

[jbirch]

It looks like there is a new FDO RFC that will allow a much faster/smaller DescribeSchema and a new EnumerateFeatureClasses method:

FDO RFC 23

If this is taken advantage of by MapGuide, will it help in the situation you are describing?

[ksgeograf]

FDO RFC 23 would most likely improve the startup time. But MapGuide would still make an unnecesary call to the provider in many cases. I have seen maps with 100+ layers, and around 8 are visible at startup, and about 2 can ever be selectable.

There would still be problems with a WFS server that just times out.

So yes, it would help out, but still leave room for improvement.

[jbirch]

Removing version from enhancement request. If this enhancement request has been addressed or is no longer required, please close ticket.

[ksgeograf]

This has not been adressed, but may be marked as "wontfix" because 2.1 handles caching of schema data much better. However, the overhead is still there, and it would be an improvement to fix this.

[jng]

I think the combination of FDO RFC23, caching of schema information and use of the GetResourceContents() API introduced in 2.2 is sufficient optimizations for resolving this issue.