[DotNet-OSGeo] some random thoughts

[John Diss]

Hi list, I thought I should note a few opinions/ideas down for further
discussion, in no particular order:

 

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.

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

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.

All external apis where possible should be parallelizable. E.g
collections should be synchronized. 

 

Data access should be async.

 

There should be a caching block developed with multiple backends. Uses
ranging from caching data/ partial screen renders, wms/wfs output etc.

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.

 

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.

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.

 

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.

 

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.

 

All data classes should be marked [Serializable].

 

Where possible the classes should be [CLSCompliant]

 

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.

 

Potential for 3D should be considered and planned for if appropriate.

 

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.

 

Labelling engine is extremely important it should be capable of creating
very crude/fast maps and also picture perfect - what the general public
expect.

 

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.

 

Source control should be backed with a CI / Test server.

 

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.

Perhaps the logs should be taken and made available somewhere.

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.

 

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

 

All the best

jd

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/dotnet/attachments/20100601/27e1e8aa/attachment.html