DeepEarthPrototype Project

Developer
Oct 24, 2008 at 3:18 AM
I would like to move the "Controls" & "Behaviors" into the own folders/namespaces in the DeepEarthPrototype Project
instead of having everything just laying in the root folder/directory

it just seems to be untidy and as more things get added will become more untidy
would people mind if I moved these things to there own places as described above...?
Coordinator
Oct 24, 2008 at 5:25 AM
Sounds good to me, we had also discussed the idea previously of introducing a "prototype" project per developer. The idea is this is the place where each person can "play" with new behaviours and controls without effecting anyone else. It would be easy to simple exclude that project in your solution.
Do people think this would be useful or just cause more work and clutter? The alternative is make a local project copy of the exisitng prototype and only commit the code into the common prototype project when you're finsihed and happy. To date we have been doing the later.
Coordinator
Oct 24, 2008 at 11:28 AM
At least as far as the controls go, I was thinking that we may want to start moving some of them back the DeepEarth project, or at the very least create a DeepEarth.Controls project to house them. It is just that something doesn't quite seem right that we have about 4 copies of the dashboard laying around. I am currently working on porting the Dashboard to an actual skinable control in the main project (with the default template being what we have been using). What do you think?
Developer
Oct 24, 2008 at 12:03 PM
Edited Oct 24, 2008 at 1:18 PM
I was thinkning about this as well, I was thinking if there are some "Core" controls like the dashboard and the little control that displays the lng & lat in the bottom right of the screen, then these could be moved into to a project of there own (single .dll)

then if there are other controls that are not critical or are something that people may or may not use in here own projects, or a group of controls that all work together... maybe these controls could be in there own project (.dll)

this is a lot of seperate projects/.dll's but it then gives the person using them in there own project the ability to choose what they want to include and thus means they can keep the final .xap file smaller, just by using the controls that they want to use and not having to have all controls by default...

it was just an idea, and I guess it depends on the amount of controls that are create etc as well...?
Coordinator
Oct 24, 2008 at 12:21 PM
That's true to a certain extent. If we break controls into many smaller projects/dlls, but people are likely to use all of them, then we have actually made things worse.
Oct 24, 2008 at 12:56 PM
Edited Oct 24, 2008 at 1:47 PM
I am for moving these basic controls back to the root project, DeepEarth.  Most people will need use of the core controls.  If we make sure the core controls are "Templatable", then users could choose to include, omit, or change (skinning) as they choose.

I am the new guy here, so take this for what its worth.  IMHO, there should be a high bar for creation of new assemblies.  If a set of functionality does not adversely affect the assembly size AND is likely to be used by most users,  why break it out?  Assemblies should be treated as be units of deployment, not organization.  There may be reasons I am not aware, but perhaps someone could help me understand why VE and OSM are separate assemblies.  From my perspective, it looks like an artificial separation.  These tend to cause redundancy, over-architecting, and even bugs.

Coordinator
Oct 24, 2008 at 2:14 PM
I totally agree that we need to be careful when considering creating too many assemblies. I am of the opinion that we should only create assemblies when it REALLY makes sense.
Coordinator
Oct 24, 2008 at 5:37 PM
I was chatting to dotnetnoobie earlier about the new route control. The issue with making a generic control is you can't hardcode specifics. For example the dashboard has Road, Aerial, Hybrid. It is VE specific. Should this really be a bindable list from what has been added to the map? It adds more work for us.
Do we want one mega control with lots of options but a large footprint or do we want a core control, actual tile/service providers and then lots of good examples for developers to use?
I think something like a dashboard is very useful but we need to make it generic to include in the core.

To defend the seperate dlls for OSM and VE the thinking is that your actually unlikely to use more then one due to licensing. There could potentially be > 10 different providers here. In this case the developer makes a decision as to what he will use and only includes that in the final XAB. It also allows businesses who arn't allowed to use a potential provider we add to the project to simple remove that project from their copy of the source.
Oct 24, 2008 at 7:57 PM
Totally agree about keeping the core navigation control very simple and generic.  Anyone who wants a specialty nav control must build their own.

Regarding licensing, isn't the question more a matter of usage.  Correct me if I am wrong, but any licensing agreement pertains to actual usage and access to a datasource (e.g. VE, or GM).  So if the primary component contained the classes that allowed access to VE, but a user chose not to go that route.  Let them go in peace.  Also, they are still free to remove classes of data sources that freak them out.

My real aversion to the separate DLL's is that I believe this separation is the cause of much of the current redundancy the project.  It screams over-architecting to me.  I can see your point if we get up to 10 datasource, so let me make the following suggestion.  A more pragmatic approach might be to incorporate the top 3 or 4 most likely to be used datasources (e.g VE, OSM, GM) and then satellite ones which are unlikely to be used or more special purpose datasources.  

Coordinator
Oct 25, 2008 at 3:41 AM
I like Rico's idea about incorporating some of the common providers into the core project. Considering that each provider only carries with it 3-4 classes (some of which should probably be shared across providers anyway), incorporating 3-4 common providers (VE, OSM, GM, and maybe WMS?) would make sense and wouldn't add any bloat to the dll.

On a side note, I think we may want to reconsider adding support for GM as I don't believe that they allow provide any license for direct tile access. Plus, I read some place (can't remember where now) that they implement a scheme to attempt to detect if a request is coming from inside their GMap control or not. If they determine that you are accessing their tiles directly and too frequently, they will add you to a black list and start denying requests.
Developer
Oct 25, 2008 at 4:03 AM
with a "WMS" provider... is this a "Standard" as I seem to find a large amount of places who have "WMS Map servers" e.g. NASA, ones for Fires,  and a heap of other places

does this mean that a "WMS" provider will work with all of these tiles servers?
Coordinator
Oct 25, 2008 at 9:21 PM
Yes, WMS is an OGC standard.
Oct 27, 2008 at 12:55 PM

With a "WMS" provider someone would most likely want to consume data from several servers so they could build a robust map for their users.

They could also want to add OpenGIS Web Feature Services (WFS) for polygons, points and lines.

http://www.opengeospatial.org/standards/wfs