[mapguide-internals] RE: Refactoring Web .NET API into Common DLLs is ready for review.

Fri Jun 26 03:23:09 EDT 2009

Silverlight would not be good, because you cannot use unmanaged code there.

But, a destop vector render that uses the MapGuide render engine is a 
good use case.
There are probably quite a few roadblocks before that happens.

The BerkleyDB wrapper is also a usefull scenario.

With the dual linkage solution proposed by Leaf, I'm pro this change.

Regards, Kenneth Skovhede, GEOGRAF A/S

Trevor Wekel skrev:
> Hi Kenneth,
>
> The SWIG/IMake infrastructure MapGuide uses is flexible enough to generate language specific enhanced wrappers for some of the API.  For example, it is possible to generate additional glue logic in the "collection" wrappers so they behave more like .Net collections.  But I haven't looked at .Net streams so I don't know if it is possible to make MgByteReader behave like a stream.
>
> Multiple assemblies should allow 3rd party developers to extend core services.  MgResourceService could be implemented using Berkeley DB, as it is now, or as a filesystem wrapper.  With a single monolithic MapGuide API assembly that bundles everything together, these sorts of extensions become more difficult to implement.  And it would be nearly impossible to build and distribute "extension libraries" using the current model.  Trace/route and geocoding libraries would be two candidates for "extensions".  Personally, I like the raw power of C++ for heavy analysis. 
>
> You are dead on with the unmanaged code.  It makes portability much more difficult.  However, having (more of) the C++ code base available through .Net may allow someone to design and build an installable MGOS vector viewer with .Net as the programmatic API.
>
> So I guess one use case would be an extensible vector viewer.  And with some trickery, you may even be able to share the C++ components between both a Java and a .Net based vector viewer.  And maybe even Silverlight, but I am not familiar enough with the technology to comment on that one.
>
> Thanks,
> Trevor
>
> ________________________________________
> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [ks at geograf.dk]
> Sent: Thursday, June 25, 2009 11:10 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] RE: Refactoring Web .NET API into Common      DLLs    is ready for review.
>
> I see no use for it with regards to Maestro.
>
> I originally skipped the MapGuide.Net API, because it is just a wrapper
> for unmanaged code.
> The unmanaged code removes all the portability benefits.
> If I were to use, say the coordinate system code, in Maestro, I would
> have to
> provide 32 and 64 bit versions, for both windows, linux and mac.
> That is too high a price for me, so I would not use it for Maestro,
> regardless of the split.
>
> The other issue is that none of the types map nicely to the .Net types,
> so eg. a stream
> cannot be handled as a .Net stream, meaning that no framework methods
> can work directly on it.
>
> So, even if you have an application that is not supposed to be portable,
> it would not be
> as easy to use as it could be. As for the geometry library, I would
> recommend TF.Net instead.
>
> I have no ideas for the use of PlatformBase or Foundation with .Net.
> The .Net framework appears to have superior native versions of much
> of what is inside those two libraries.
>
> I there were a clear use case for the split, it would be easier to
> comment on.
>
> Regards, Kenneth Skovhede, GEOGRAF A/S
>
>
>
> Jason Birch skrev:
>   
>> I understand the theoretical benefits I guess, but I'm not convinced that there is concrete demand that justifies disrupting all of the existing .Net applications.
>>
>> I personally haven't seen people clamouring to re-use the MapGuide APIs outside of MapGuide web apps.  This change causes additional work for existing implementations, has the potential to cause confusion for existing and new users, creates a divergence between the .Net/PHP/Java APIs, and doesn't appear to have a strong foundation in community demand.
>>
>> I'd be interested in whether our resident .Net desktop developers see ways this could benefit their applications (such as Maestro and FDO Toolbox).
>>
>> Jason
>>
>> -----Original Message-----
>> From: Leaf Li
>> Sent: Thursday, June 25, 2009 7:04 AM
>> Subject: [mapguide-internals] RE: Refactoring Web .NET API into Common DLLs is ready for review.
>>
>> The key motivation of this RFC is to let other application be able to resue MapGuide's code.
>> 1. It is ture .NET developer need update their project to add new reference after this RFC is implemented. However, they may still need rebuild their project without this RFC after using a new version of MapGuide because of some changes to .NET API. So adding some new references to their project is really a minor changes.
>> 2. Currently MapGuide .NET Web API depends on MapGuide environment. It is nearly for other application to reuse MapGuide .NET API. After refactoring MapGuide .NET Web API into some common dlls, APIs in Foundation, Geometry and PlatformBase components can be completely used by other applicaiton such as coordinate system API. In that time, MapGuide is not only a Web GIS platform. but also a GIS platform which can be used by both desktop applicaiton and web applicaiton.
>>
>> Thanks,
>> Leaf Li
>>
>> ________________________________________
>> From: Leaf Li
>> Sent: Thursday, June 25, 2009 6:47 PM
>> To: mapguide-internals at lists.osgeo.org
>> Subject: RE: Refactoring Web .NET API into Common DLLs is ready for review.
>>
>> I think Jason just gave us a very good sample of one of the benefits to this RFC. Users can develop other application based on MapGuide API. Actually those application can be both desktop and web application. I am not sure whether we can have a MapGuide .NET Desktop SDK currenlty. It isn't difficult for users to copy several files manually before we have it as long as we document it.
>>
>> Thanks,
>> Leaf Li_______________________________________________
>> 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
>   