[DotNet-OSGeo] some random thoughts

[Daniel Ames]

John,

Nicely summarized - I think you've pretty much laid out all of the main
considerations in designing a common .NET underlying framework... Here are
some thoughts on your points.

- Dan

Personally I think all parts of the application should be split into an
> interface and an implementation. All interfaces should only demand other
> interfaces in their contracts. This will allow much easier replacement of
> core components in future. IOC/DI can be used to bind the concrete
> implementations together. We should avoid building a tightly coupled
> monolith.
>
Agreed. It's the question of building an open source cathedral or an open
source bazaar. Maybe what we need is a well-planned city where individuals
can contribute different elements but they all fit together.

>
> All interfaces should closely resemble their OSGeo counterparts - there is
> no point in building a standard if by doing so you ignore the standard.
>
Critical imao

>
> Licensing should be thought out up front. The project will never be the
> go-to source for .Net developers if there is the slightest hint of GPL and a
> lot of people don’t understand LGPL either so that is also a turnoff.
>
On some of our projects we are going with BSD which is like LGPL in spirit
but is only one paragraph which is nice. Alternatively we continue to use
LGPL and make sure to educate people as to what that means (ie. commercial
use is OK).

>
> All external apis where possible should be parallelizable. E.g collections
> should be synchronized.
>
Cool, but not sure how feasible. Thoughts?

>
>
> Data access should be async.
>
Especially for web based data access. Maybe not for file based?

>
>
> There should be a caching block developed with multiple backends. Uses
> ranging from caching data/ partial screen renders, wms/wfs output etc.
>
Not sure exactly what the implications are... but interesting idea.

>
> Supported frameworks should be considered up front - my personal preference
> would be to start with a clean slate at .Net 4 or at a minimum 3.5.
>
We were targeting 3.5 because it would be more likely to be mono
compliant... (does MONO really support all of .NET 4 now?)

>
>
> If we hope to support MONO (which I think we should) we must ensure that
> any rendering api's have a potential replacement in Mono. Mono is currently
> compatible with .net 4.
>
 Any ideas on how much of .NET 4 is implemented in MONO now?

>
> GDI+ is terrible in a server context - "A Generic Exception Occurred" is
> the best way to ruin my day/week/month. A while ago I had a play with Cairo
> and D2D both are promising - wip is available in the JDSymbolizer branch at
> http://sharpmapv2.googlecode.com. D2D is platform agnostic whereas the
> Cairo I was using was x86 only. It was also an experiment to allow different
> rasterizers to be used in the same control and also multi pass rendering ala
> OsGeo Symbology.
>
Our approach has been to - again - use interfaces. So we have developed an
"iMap" interface that could be swapped out with different rendering engines
depending on the platform or user preference. We need to commit this soon to
the System.Spatial codeplex site and get some feedback from others.

>
>
> Reliance on native apps/dlls should be avoided where possible and replaced
> asap when they are used to get a result. They reduce the portability of the
> resulting framework and make building for AnyCPU much harder as you get
> BadImageFormatExceptions thrown whenever an x86 native assembly is loaded
> into an x64 app domain. This in turn makes the build configs harder to
> maintain.
>
Agreed. This is why it's important to for example support GDAL as a data
provider plug-in. Essentially any native app or dll needed should be
supported as a plug-in rather than as a core framework component.

>
>
> Any class expecting to retrieve (vector/attribute) data from a datasource
> should demand IQueriable<I/TFeature> rather than a FeautureProvider or
> similar. DataTable / Dataset should be avoided. The query syntax should be
> either linq against TFeature and/or based on expressions taken from the
> OSGeo Filter spec.
>
Not sure I understand... can you explain further?

>
>
> All data classes should be marked [Serializable].
>
Agreed

>
>
> Where possible the classes should be [CLSCompliant]
>
Agreed

>
>
> Any style/symbology should be based on the OsGeo symbology spec /SLD i.e
> multiple rules evaluated in a loop for each feature allowing for complex
> styles to be built up.
>
Agreed. We've started using this approach in a new renderer for MapWindow
that we'd like to share with the community in the
System.Spatial.Symbology(?) namespace...

>
>
> Potential for 3D should be considered and planned for if appropriate.
>
One approach is through the iMap interface. Using the common interface for a
map would allow someone to build an OpenGL or DirectX map and swap it in
with full 3-D capabilities.

>
>
> Silverlight/Moonlight has massive potential for browser based gis / mapping
> / processing / grid computing. Supporting it should definitely be planned
> for but it imposes its own forced async style which may have implications
> elsewhere. Also win phone 7 will be Silverlight based. Novell have MonoTouch
> and MonoDroid in progress for IPhone and Android respectively and
> www.KoushikDutta.com  is working on another free Android/Mono platform.
>
What are all the implications of supporting Silverlight and Moonlight? Is it
possible to have a standard .NET DLL that can be used in a Silverlight
application?

>
>
> Labelling engine is extremely important it should be capable of creating
> very crude/fast maps and also picture perfect – what the general public
> expect.
>
Yes. ArcGIS does this by having a pretty good labeling engine and then an
expensive add-on (Mapplex) that does the atlas style labeling - which is
nicer but slower. So there needs to be support for both, perhaps with better
labeling available through a plug-in. We ought to be able to reuse/port from
other good open source labeling engines...

>
>
> MS C#/dotspatial group style guidelines should be followed -  everyone’s
> code should look the same. Perhaps a developer R#/stylecop profile should be
> created and enforced by a CI server.
>
Agreed. Is it possible to do this kind of enforcement using Codeplex?

>
>
> Source control should be backed with a CI / Test server.
>
Can this be done on Codeplex?

>
>
> There should be an IRC channel created or perhaps 2. #dotspatial and
> #dotspatial-dev. I suggest freenode.net as #OSGeo and #SharpMap are
> already there.
>
Agreed - will do.

Perhaps the logs should be taken and made available somewhere.
>
Yeah, any ideas on how to do this other than just through the codeplex log
browser?

>
> Documentation should be easy to find and of high quality. Perhaps the group
> needs a sister website separated from codeplex where it is easier to manage
> the wiki/ public contribution etc. The codeplex wiki is very limited in this
> respect.
>
Yes agreed. This is the number one complaint I believe of any/every open
source GIS project that there isn't adequate high quality documentation.
We've registered "dotSpatial.org" so maybe that should point to a
non-Codeplex server where we can maintain documentation and project
description/etc. Then have pointers to the Codeplex site for source code,
issues and forums. What do you think of this approach? Would you (John or
others) be interested/willing to help decide what would go such a separate
site? layout, etc?

>
>
> Any way got to do some work.. more to come...
>
>
>
> If possible it would be good to arrange an informal meeting sometime on
> irc.  I am in London, FObermaier is in Germany and Pauldendulk is in Holland
> so it may make sense to have it late afternoon here / morning in the US
>
Agreed. I'll set up the freenode channel unless someone else has already
done it and then let's schedule a chat for anyone interested in joining...

>
>
> All the best
>
> jd
>
>
>
> _______________________________________________
> DotNet mailing list
> DotNet at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dotnet
>
>


-- 
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani at isu.edu
geology.isu.edu
www.mapwindow.org

*************************************************************************
See you at IEMSS 2010: http://www.iemss.org/iemss2010/
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/dotnet/attachments/20100601/6fdbf57e/attachment-0001.html