[DotNet-OSGeo] some random thoughts

Tue Jun 1 14:41:51 EDT 2010

Hi Ted,

Xlinq may be a source of inspiration for querying arbitrary datasources.

Also code along the lines of
SomeRepository<Feature>().Where(o=>o.Property<int>("somepropertyname")==
1 && o.Geometry.Intersects(anotherGeometry)) may work..

 I am happy with the use of System.Reflection and Lightweight Code
Generation for doing dynamic binding - the only place where I know it
would be an issue would be on IPhone where all code must be statically
compiled.

Due to an editing error I missed out the crucial part :  Jetbrains give
free licenses to OSS developers
http://www.jetbrains.com/resharper/buy/buy.jsp#openSource 

I think VS express may be a bit lightweight to develop the actual
framework but should be more than enough to consume it. MonoDevelop
seems to have come on quite a long way and is compatible with .sln
files.

VS Express is missing several very useful features such as source
control bindings and iirc it limits the number of projects in a
solution/ doesn't allow web projects mixed with windows etc.

WRT GDAL/OGR - it would be a monster to replace, but equally I don't
think it  should be a compulsory module. As an optional module it is
fine. For SharpMap 2 we have also been working with the assumption that
it is too big to rewrite just now.

BTW the best way to see where we are with SharpMap would be to pull the
v2 trunk and build -  make sure you build as a Net20 profile - Net35 is
a bit broken currently. SVN should take care of getting correct versions
of NTS, GeoAPI, ProjNet and NPack. As ever there is not enough
documentation but some useful code.
http://sharpmapv2.googlecode.com/svn/trunk
<http://sharpmapv2.googlecode.com/svn/trunk>  

Cheers jd

From: Harold Dunsford [mailto:hadunsford at gmail.com] 
Sent: 01 June 2010 19:06
To: John Diss
Cc: Daniel Ames; dotnet at lists.osgeo.org
Subject: Re: [DotNet-OSGeo] some random thoughts

So this is a great conversation thread that you guys are starting.  I
have a lot of experience with working more towards the pure windows
forms application side of things, and less so as far as setting up web
stuff, so we can use ideas about how we need to tweak things for optimal
compatibility with as many folks as possible.  I agree with the
principals outlined in the previous posts and much of this is simply
good coding convention.  I have been using resharper in order to set up
some formatting rules, but I suspect that people won't necessarily want
to pay for it, so if you know of something else to help with that, I'm
interested.  I like trying to set things up so that people can use C#
express in order to work with the libraries, however, I am getting
reports that people writing plug-ins might not be able to have their
plug-in launch an external program for debugging from the express
version.  Also, I'm not sure about the implications with trying to use
system.Reflection for run-time referencing in other platforms.  Is it ok
to use, for instance, a plug-in architecture for referencing OGR/GDAL,
or should we be thinking in terms of porting content to C#?  

So we currently have source code that is good for accessing shapefile
data in C#, but it doesn't offer anything close to what OGR or other
vector providers could do.  It also relies heavily on the unmanaged GDAL
libraries in order to support various image/raster data formats, via a
plug-in architecture.  Unfortunately, according to your comments, it
also makes use of DataTables.  (It can either load all the data at once
for small dbf files, or can set up a page query to take advantage of the
virtual data tables in .Net, but it does not take advantage of the new
IQueriable structures or linq)  I like linq, but what I have done with
it tends to work extremely well for scenarios where the developer knows
the schema ahead of time, and I'm not sure how well it works in
situations where you were dealing with the unknown schema.  However, I'm
sure there is a way to make all that work, I just haven't done much of
it yet, but would not mind tailoring our data access libraries to move
more in that direction.

Once Dan sets up an IRC line, I will be happy to get on it.  I'm not a
current IRC user, (we used Windows Live Messenger).  However, I have no
problem switching over to that. 

I'm really looking forward to getting our libraries out there in a way
that is more useable and more versatile for everyone.  I also appreciate
the time that you guys are putting in in order to take this idea
seriously.

Ted Dunsford (Shade1974)

On Tue, Jun 1, 2010 at 10:12 AM, John Diss <john.diss at newgrove.com>
wrote:

Hi Dan please see comments inline:

Also you may be interested in Mono.Addins and MEF for your plugin
architecture consideration.. alternatively spin up new App Domains to
host your plugins.

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

Cool, but not sure how feasible. Thoughts? 

I am thinking along the lines of the new System.Collections.Concurrent
namespace. Computers aren't getting any faster - we need to make sure we
can use as many cores as possible to get the speed gains we need.

Parallelization is also very hard to retrofit so if we can get a plan in
early we will benefit.

	Data access should be async.

Especially for web based data access. Maybe not for file based? 

IMO all IO bound access should follow the same pattern : web, db or
file. There is no point hitting datasources sequentially when you can do
so in parallel. 

	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. 

Basically have a generic caching block with rules for scavenging and a
variable backing store which can be plugged into any part of the
processing /rendering pipeline. It could be equally at home as an
in-memory cache of features on a layer or as an image cache speeding up
identical wms requests. - There is some work on this in the asp.net bits
of SharpMap2 but it could be made more generic..

	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?)  

Miguel certainly seemed to think so in a vid I saw recently..
http://mono-project.com/Compatibility tells a slightly different story -
but being an OSS project the documentation is out of date and probably
wrong J I will try and locate the vid.

	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? 

See above - I think they are also working on making the GC better.

	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? 

It was partly a spelling mistake on my part: should have been
IQueryable<IFeature> which is basically the underpinning of Linq. 
The OsGeo filter spec details a dialect for describing a query which is
similar to the System.Expressions namespace used in defining Linq
queries. Both would also provide an easy mechanism for
serializing/persisting queries. 
Datasets and DataTables are very heavy/ verbose and don't exist on
certain platforms. Pretty much all the trends as far as I can see, is to
kill them off in favour of domain entities / ORM. DataTables / Datasets
are also frowned upon in WCF which is another set of technology that
could be very useful in this field. We have an expression model in
SharpMap 2 but it is a bit clunky at the moment and disconnected from
linq.

	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? 

The binaries are compatible at .net 4 not so previously afaik.
Silverlight is both a super and sub set of  WPF so there are
differences. System.Data is one key difference. IMO WPF and Silverlight
will merge into one over the next couple of releases. 

	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? 

I don't think codeplex allows this. I have heard good things about
Jetbrains' TeamCity  and lots of people use CruiseControl. BTW jetbrains
give away R# licenses.

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

Can this be done on Codeplex? 

Not afaik.

	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? 

I actually meant the IRC logs.

	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?

I am happy to help out wherever I can..

_______________________________________________
DotNet mailing list
DotNet at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/dotnet

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