RE: Refactoring Web .NET API into Common DLLs is ready for review.

[Leaf Li]

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Leaf Li]

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: [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jason Birch]

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: [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jackie Ng]

I might find the Coordinate Transformation stuff useful, but that doesn't really do much without the 300-400MB of CS dictionaries correct?

I can't really see how the rest of these libraries can/could be used from a desktop perspective

- Jackie

Jason Birch wrote:

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: [e-mail]
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
[e-mail]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[e-mail]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Andy Morsell]

Item 1 also has me very concerned.  There are a lot of existing .NET based
MGOS / MGE applications out there.  Some are in direct control of the user
so they may be able to update their .NET project, but many are delivered by
consultants.  W the user updates to a newer release of MGOS / MGE it is not
a good idea for their application to be broken and then have to go back to a
consultant to fix it for them.  For these types of folks (not programmers),
they won't know that their application will break until it's too late.

Your statement of " they may still need rebuild their project without this
RFC after using a new version of MapGuide because of some changes to .NET
API" also has me concerned.  Can you please elaborate on this a little?

Thank you.

Andy


-----Original Message-----
From: Leaf Li [mailto:[hidden email]]
Sent: Thursday, June 25, 2009 7:04 AM
To: [hidden email]
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: [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Kenneth Skovhede, GEOGRAF A/S]

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: [hidden email]
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> 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

[Kenneth Skovhede, GEOGRAF A/S]

There was (again) some changes to the inheritance of one or more classes,
with regards to the MgDisposable and MgGuardedDisposable,
so the current .Net dll will not work with updated native dll's.

The current natives will not work well with the new MG server.

However, it is possible (a bit cumbersome though) to bind to
the new version of the .Net assembly, using web.config or app.config,
and thus use the new dll without recompiling.

Splitting the dll would remove that option.

Regards, Kenneth Skovhede, GEOGRAF A/S



Andy Morsell skrev:

> Item 1 also has me very concerned.  There are a lot of existing .NET based
> MGOS / MGE applications out there.  Some are in direct control of the user
> so they may be able to update their .NET project, but many are delivered by
> consultants.  W the user updates to a newer release of MGOS / MGE it is not
> a good idea for their application to be broken and then have to go back to a
> consultant to fix it for them.  For these types of folks (not programmers),
> they won't know that their application will break until it's too late.
>
> Your statement of " they may still need rebuild their project without this
> RFC after using a new version of MapGuide because of some changes to .NET
> API" also has me concerned.  Can you please elaborate on this a little?
>
> Thank you.
>
> Andy
>
>
> -----Original Message-----
> From: Leaf Li [mailto:[hidden email]]
> Sent: Thursday, June 25, 2009 7:04 AM
> To: [hidden email]
> 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: [hidden email]
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>  

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

[Leaf Li]

Thanks for you useful comments. I totally understand your concerns.

1. Yes. We didn't see people clamour to re-use the MapGuide APIs outside of MapGuide web apps. It is just because we didn't refactor Web API into some common dll and users can't do it outside of MapGuide. Through this RFC, people will be aware that they can use MapGuide API outside of MapGuide. Personally, I believe this RFC is just the first step.
2. I think some of open source projects can be beneficial from it such as FDO Toolbox. By the refactored API, FDO Toolbox can add more functionality easily such as geometry coordinate system transformation.
3. Actually there are already some projects and products which is trying to reuse MapGuide Web .NET API such as Map 3D. I think they can be beneficial from it.

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

[Trevor Wekel-3]

Hi Kenneth,

The .Net assembly dll is generated during every build from the C++ header files using SWIG.  The binding is very specific.  Mixing and matching old .Net assemblies with new C++ dlls is almost guaranteed to break.  The entire assembly and dll package should be considered a single unit.  The same goes for the PHP and Java bindings.

When I get some more time to work on the automated builds over the next few weeks, we should be able to generate more regular builds of MGOS so mixing and matching will not be as necessary.

Thanks,
Trevor



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [[hidden email]]
Sent: Thursday, June 25, 2009 11:14 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RE: Refactoring Web .NET API into Common      DLLs    is ready for review.

There was (again) some changes to the inheritance of one or more classes,
with regards to the MgDisposable and MgGuardedDisposable,
so the current .Net dll will not work with updated native dll's.

The current natives will not work well with the new MG server.

However, it is possible (a bit cumbersome though) to bind to
the new version of the .Net assembly, using web.config or app.config,
and thus use the new dll without recompiling.

Splitting the dll would remove that option.

Regards, Kenneth Skovhede, GEOGRAF A/S



Andy Morsell skrev:

> Item 1 also has me very concerned.  There are a lot of existing .NET based
> MGOS / MGE applications out there.  Some are in direct control of the user
> so they may be able to update their .NET project, but many are delivered by
> consultants.  W the user updates to a newer release of MGOS / MGE it is not
> a good idea for their application to be broken and then have to go back to a
> consultant to fix it for them.  For these types of folks (not programmers),
> they won't know that their application will break until it's too late.
>
> Your statement of " they may still need rebuild their project without this
> RFC after using a new version of MapGuide because of some changes to .NET
> API" also has me concerned.  Can you please elaborate on this a little?
>
> Thank you.
>
> Andy
>
>
> -----Original Message-----
> From: Leaf Li [mailto:[hidden email]]
> Sent: Thursday, June 25, 2009 7:04 AM
> To: [hidden email]
> 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: [hidden email]
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

_______________________________________________
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

[Trevor Wekel-3]

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: [hidden email] [[hidden email]] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [[hidden email]]
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: [hidden email]
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> 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_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jackie Ng]

I guess the problem may be that there is a perception that the MapGuide Web API can only be used for web applications (maybe something to do with having "Web" in its name? :-))

There are a whole class of ASP.net libraries which share this problem. They are all .net assemblies, but serve no real purpose when used outside the context of ASP.net.

So while the MapGuide API may have use outside of web applications. It's not readily made apparent for the rest of us what these uses could be.

If this splitting into smaller dlls means that I can avoid web-specific trappings like having to call MgInitializeWebTier() with a webconfig.ini to start the whole thing, then I would be supportive of such a move.

- Jackie

Leaf Li wrote:

Thanks for you useful comments. I totally understand your concerns.

1. Yes. We didn't see people clamour to re-use the MapGuide APIs outside of MapGuide web apps. It is just because we didn't refactor Web API into some common dll and users can't do it outside of MapGuide. Through this RFC, people will be aware that they can use MapGuide API outside of MapGuide. Personally, I believe this RFC is just the first step.
2. I think some of open source projects can be beneficial from it such as FDO Toolbox. By the refactored API, FDO Toolbox can add more functionality easily such as geometry coordinate system transformation.
3. Actually there are already some projects and products which is trying to reuse MapGuide Web .NET API such as Map 3D. I think they can be beneficial from it.

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

[Kenneth Skovhede, GEOGRAF A/S]

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: [hidden email] [[hidden email]] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [[hidden email]]
> 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: [hidden email]
>> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> 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_______________________________________________
> 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