[mapguide-internals] Generating Xml for "Select Features"
trevor.wekel at autodesk.com
Tue Jun 26 14:46:32 EDT 2007
ToXml() is marked as EXTERNAL_API in MgReader so changing the signature
could break some code. Also, all PUBLISHED_API and EXTERNAL_API within
MapGuide have to function correctly for all 3 web languages - PHP, .Net,
and Java. Implementing API support for native streaming in all three
languages would be a non-trivial effort.
To get around the 16MB limit, write the string to a file and use new
MgByteSource("filename", true). I would only do this is the string is
Increasing the 16MB limit on MgByte is probably not a good idea,
especially for this API. Selecting an entire feature source (like the
US roads network) into an in-memory XML blob would be bad.
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
Kenneth, GEOGRAF A/S
Sent: Tuesday, June 26, 2007 5:26 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] Generating Xml for "Select Features"
When using the "Select Features" from the Http API, the result comes
back in Xml.
The call chain is:
MgByteSource::MgByteSource(char* data, int len)
ByteSourceMemoryImpl::ByteSourceMemoryImpl(char* data, int len)
MgByte::MgByte(char* data, int len, AllocatorType allocator)
When the size of the Xml to return grows, MgByte throws an exception in
if (len > MgByte::MaxSize && allocator != MgByte::None)
throw new MgArgumentOutOfRangeException(L"MgByte.MgByte",
__LINE__, __WFILE__, NULL, L"", NULL);
This happens because the ByteSourceMemoryImpl does not pass an
AllocatorType argument, and thus defaults to MgByte::None.
A simple solution would be to fix this error in ByteSourceMemoryImpl,
but I don't have enough overview to see if this has other implications.
I will happily submit a patch for ByteSourceMemoryImpl, but is that an
I would prefer if the code was changed, so that
ProxyFeatureReader::ToXml() took a stream as input, and wrote to that
That would also improve response/perfomance time, as the current
implementation buffers the entire result, and also uses the std::string
+ operator, which has a high overhead for large strings.
Is the second solution something that could be accepted as a patch? I
so, I will happily submit a patch for it.
Regards, Kenneth, GEOGRAF A/S
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
More information about the mapguide-internals