<div class="gmail_quote"><div>John, </div><div><br></div><div>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.</div>
<div><br></div><div>- Dan</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div><p>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.</p></div></div></blockquote><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="color:black">
<br>
All interfaces should closely resemble their OSGeo counterparts - there is no
point in building a standard if by doing so you ignore the standard.<br></span></p></div></div></blockquote><div>Critical imao </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="color:black">
<br>
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.<br></span></p></div></div></blockquote><div>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). </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="color:black">
<br>
All external apis where possible should be parallelizable. E.g collections
should be synchronized.</span></p></div></div></blockquote><div>Cool, but not sure how feasible. Thoughts?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple">
<div><p><span style="color:black"> </span></p>
<p><span style="color:black"> </span></p>
<p><span style="color:black">Data access should be async.</span></p></div></div></blockquote><div>Especially for web based data access. Maybe not for file based? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">There should be a caching block
developed with multiple backends. Uses ranging from caching data/ partial
screen renders, wms/wfs output etc.<br></span></p></div></div></blockquote><div>Not sure exactly what the implications are... but interesting idea. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="color:black">
<br>
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.</span></p></div></div></blockquote><div>We were targeting 3.5 because it would be more likely to be mono compliant... (does MONO really support all of .NET 4 now?) </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">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.<br></span></p></div></div></blockquote><div> Any ideas on how much of .NET 4 is implemented in MONO now? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="color:black">
<br>
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 <a href="http://sharpmapv2.googlecode.com" target="_blank">http://sharpmapv2.googlecode.com</a>. 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.</span></p></div></div></blockquote><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">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.</span></p></div></div></blockquote><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">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.</span></p></div></div></blockquote><div>Not sure I understand... can you explain further? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">All data classes should be
marked [Serializable].</span></p></div></div></blockquote><div>Agreed </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple">
<div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">Where possible the classes
should be [CLSCompliant]</span></p></div></div></blockquote><div>Agreed </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple">
<div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">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.</span></p></div></div></blockquote><div>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... </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">Potential for 3D should be
considered and planned for if appropriate.</span></p></div></div></blockquote><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">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 <a href="http://www.KoushikDutta.com" target="_blank">www.KoushikDutta.com</a> is
working on another free Android/Mono platform.</span></p></div></div></blockquote><div>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? </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">Labelling engine is extremely
important it should be capable of creating very crude/fast maps and also picture
perfect – what the general public expect.</span></p></div></div></blockquote><div>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... </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">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.</span></p></div></div></blockquote><div>Agreed. Is it possible to do this kind of enforcement using Codeplex? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">Source control should be backed
with a CI / Test server.</span></p></div></div></blockquote><div>Can this be done on Codeplex? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple">
<div>
<p><span style="color:black"> </span></p>
<p><span style="color:black">There should be an IRC channel
created or perhaps 2. #dotspatial and #dotspatial-dev. I suggest <a href="http://freenode.net" target="_blank">freenode.net</a>
as #OSGeo and #SharpMap are already there.</span></p></div></div></blockquote><div>Agreed - will do. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black">Perhaps the logs should be
taken and made available somewhere.<br></span></p></div></div></blockquote><div>Yeah, any ideas on how to do this other than just through the codeplex log browser? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="color:black">
<br>
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.</span></p></div></div></blockquote><div>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?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p><span style="color:black"> </span></p>
<p class="MsoNormal">Any way got to do some work.. more to come...</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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</p></div></div></blockquote><div>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... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple"><div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">All the best</p>
<p class="MsoNormal">jd</p>
<p class="MsoNormal"> </p>
</div>
</div>
<br>_______________________________________________<br>
DotNet mailing list<br>
<a href="mailto:DotNet@lists.osgeo.org">DotNet@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/dotnet" target="_blank">http://lists.osgeo.org/mailman/listinfo/dotnet</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Daniel P. Ames, Ph.D. PE<br>Associate Professor, Geosciences<br>Idaho State University - Idaho Falls<br><a href="mailto:amesdani@isu.edu">amesdani@isu.edu</a><br><a href="http://geology.isu.edu">geology.isu.edu</a><br>
<a href="http://www.mapwindow.org">www.mapwindow.org</a><br><br>*************************************************************************<br>See you at IEMSS 2010: <a href="http://www.iemss.org/iemss2010/">http://www.iemss.org/iemss2010/</a><br>
*************************************************************************<br><br>