MapGuide RFC 68 - Refactoring Web .NET API into Common DLLs is ready for review.

[Leaf Li]

All,



Please review MapGuide RFC 68 - Refactoring Web .NET API into Common DLLs <http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68#MapGuideRFC68-RefactoringWeb.NETAPIintoCommonDLLs> .

http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68

Post any comments or questions to the mailing list.



Thanks,

Leaf Li

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jackie Ng]

Is the current MapGuideDotNetApi.dll that "heavy" that it needs to be split up into multiple sub-assemblies?

And also, just a personal thing really, I never really knew which MG API classes were Foundation, which were PlatformBase, etc since they all resided under the OSGeo.MapGuide namespace. Having these classes split up but still under the same namespace will no doubt cause some (short term) confusion.

So is my first point enough justification for the move?

- Jackie

Leaf Li wrote:

All,



Please review MapGuide RFC 68 - Refactoring Web .NET API into Common DLLs <http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68#MapGuideRFC68-RefactoringWeb.NETAPIintoCommonDLLs> .

http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68

Post any comments or questions to the mailing list.



Thanks,

Leaf Li

_______________________________________________
mapguide-internals mailing list
[e-mail]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Kenneth Skovhede, GEOGRAF A/S]

I'm not against the change, but the dll itself is close to
"ultra-lightweight".
It does not contain any code, it just relays all calls to the native dll's.
If the client code does not call the methods, the native dll's won't load,
and won't be required.

I find it easy to understand that to use MapGuide, I have to include
MapGuideDotNetAPI.dll,
splitting the files would not make that easier to understand.

As Jackie noted, it is not always easy to guess what dll/namespace
contains a
specific feature.

Splitting the dll's should be done for all the supported API languages,
unless there is a desire to favor .Net.

Could you provide a use case where the split dll's will be better?

Regards, Kenneth Skovhede, GEOGRAF A/S



Leaf Li skrev:

> All,
>
>
>
> Please review MapGuide RFC 68 - Refactoring Web .NET API into Common DLLs <http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68#MapGuideRFC68-RefactoringWeb.NETAPIintoCommonDLLs> .
>
> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68
>
> Post any comments or questions to the mailing list.
>
>
>
> Thanks,
>
> Leaf Li
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>  

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jason Birch]

Hi all,

I personally don't see the utility in separating MapGuide module into separate libraries, and lots of potential confusion.  I also have a question about backwards compatibility for the .Net users.

In general, PHP modules cover a broad swath of functionality (everything related to a single technology), and users configure them once in the php.ini file and don't worry about them again.  I'm not sure how this works in .Net, but I'd imagine that many users would be surprised to have to reference multiple DLLs just to build a MapGuide web app.

Up until this point, developers haven't needed to have an understanding of where in the code an API is implemented.  Indeed, the documentation is not broken down by these classifications, but instead by services, which is how most MapGuide developers understand the code.  Forcing developers to understand the underlying distribution of the code would add unnecessary complexity to an environment that already has a relatively steep learning curve.

A question I have (as a non-.Net developer) is whether this change will require existing applications to be modified to individually reference all of the DLLs (or just the ones needed if the developer can figure that out) rather than the single DLL.

I guess I'm having difficulty accepting the reasoning behind this change, and a justification of "isn't good for users" isn't a clear enough reason for me.

Perhaps a concrete example of a case where this refactoring would be advantageous would help me to understand how this would outweigh the potential confusion caused by this change?  Is this a change that is only beneficial to users developing desktop applications based on the MapGuide APIs?  If so, will we be seeing a MapGuide .Net Desktop SDK at some point?

Jason

-----Original Message-----
From: Leaf Li
Sent: Tuesday, June 23, 2009 6:45 PM
Subject: [mapguide-internals] MapGuide RFC 68 - Refactoring Web .NET API into Common DLLs is ready for review.

Please review MapGuide RFC 68 - Refactoring Web .NET API into Common DLLs
http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals