This project is read-only.

Assembly Packaging...

Nov 12, 2008 at 4:01 AM
Edited Nov 12, 2008 at 4:02 AM
I'd like to open a dialog on the topic of assembly packaging.  This was discussed briefly in another topic, but this is an important discussion and probably deserves its own topic.  So previously we touched upon the design merits of single versus multiple assembly for packaged representation of DeepEarth.  There were good reasons for both sides. 

Single Assembly Approach:  Provides one stop shopping.  A user can quickly link to the assembly, set some props and, boom, up and running in minutes.  This also makes “refactoring as you go” much easier.  The downside is that there may be TileSource providers in your assembly that go unused and add to the total assembly size.  Also, envisioning a large number of future providers this approach can get out of hand if there are ever as many as 10+ providers as stated.

Multiple Assembly Approach:  Provides the ability for a user to pick and choose your TileSource providers at an assembly level.  If you don’t care for Virtual Earth and don’t want anything to do with it, you don’t even have to link to it.  The downside of this approach is that it makes the out of box experience, development, and deployment more difficult than it has to be. I’ll go on to contend that this separation has been the cause of several bugs and unnecessary code duplication. 

So a compromise may be available to give us the best of both worlds. As previously suggested, we could meet in the middle where we take a select few core TileSource providers for the primary project (e.g. VE, OSM) and maybe one or two more TBD.  Beyond that, satellite assemblies must be created for TileSource providers we do not agree are core in nature. 

Please provide your feedback.  

Nov 12, 2008 at 4:37 AM
First off just wanna say after reading up about this project I am really interested in trying this control out however the latest source doesn't seem to build for me.

Secondly I would like to flip your idea upside down. Keep in mind I don't know the API of your control much but it sounds like your discussing having 1 easy to wire up / use control but worried about bloat.

Just from reading your description it sounds like the main classes can be fed providers, which means many assemblies being required to wire up the control.

What about instead of thinking top down, think bottom up. For example what if the base functionality + tiling interface was defined, but the actual control was the one which includes the tiling source for example:

VEMapControl, GoogleMapControl etc which inherit from the class which provides the base functionality.

This way people can still have easy 1 assembly wire ups, but each one of these share the base functionality from the same source. Meaning if you only want to embed one control, you can do so without the bloat from the other controls.

It does mean some duplication though if you want to support multiple providers.

I'm not sure if this is the best approach but I thought I would bring up the concept.

I'm a big advocate of easy to wire up controls. Complicated community projects tend to steer away the simple user trying to wire it up and finds something not working and just deletes it.

I've seen so many great projects never succeed because of the polish of the usage/install experience. Just my 2 cents :)
Nov 12, 2008 at 5:04 AM
to make the project compile if it does not from the download...

what I do is...

  • goto each "web" project that is hosting the silverlight control,
  • then goto the project "properties",
  • I remove the link to the silverlight project and then just added the link back to the silverlight project again
  • then I just remove the new generated files that linking the silverlight project adds to the web project and run it,
  • project should load...
you need to get a developer licence/key etc for the "Virtual Earth" maps

and I have just noticed that the project is loading for the "OSM" maps,
but the map is not being displayed, no errors....
just no maps showing...?  :(

but right now I am only using the "Express" versions of VS and it does not have all the goodies of the proper version of VS, like "Solution Folders", but I do not think ,that this is the issue
I stuffed my PC, so I am on a PC for the moment without a full version of VS :(
Nov 12, 2008 at 5:23 AM
"Assembly Packaging"

I was chatting about this to "Soul" a while ago, the idea I had was to have a property in the Map Control, this is like a enum of the different providers, the user of the map control adds the map to there project and just sets the property to the tile provider they want then the map would download that assembly that contains the code etc for that tile provider when the project loads

this way a user of the control only needs to deploy the assembly for that tile provider, or could have severial and let there end users switch on the fly...?  but the idea was to keep the download/load up time down

you could also do the same for some basic controls.... e.g. the Dashboard, Find, Route controls, add some generic interfaces into the main project for these controls then you could have different assemblies that were accessing this information from different sorces... e.g. someone who wants to use the OSM maps and does not want to pay for a licence to the Virtual Earth web services to do a find or route, there controls could download a different assembly that used the web services for example...?

anyway these are just what I was thinking and I don't know how complicated you think this would make everything?

but the idea behind it is to make the load up times as quick as possible and not to load up a heap of code that is never going to be used by a persons project...
Nov 12, 2008 at 5:31 AM
Also keep in mind if you want this control to be drag n drop in VS or Blend. If you want a control / library to be successful it needs that polish where a user will have success when trying to use it like any other control / library they are used to.

I like the enum because it allows designer support.

My example basically would mean a control per tile provider. Meaning there would be duplicate code in each assembly perhaps, but if you were using just 1 provider, you would not have the code of all the other providers.

Another option is a compiler directive. Someone linking the mapping control project to their project could enable mapping providers via compiler directive. This would mean no code gets compiled for mapping providers they exclude. Enums could also be disabled as options via the compiler directive.

By default the project would have all providers defined in compiler directives for a slick default experience. However trimming the library is just a matter of removing unused compiler directives associated to mapping providers in the project settings.

1 assembly could contain all the providers they wish to configure in this manner.

I kind of like the web.config idea except there is DeepZoom coming to WPF so that idea breaks down in that application.
Nov 12, 2008 at 7:13 AM
Thanks dotnetnoobie for the feedback.  I share with you and "Soul" your concern for keeping downloads small and quick.  So let's quantify what we're talking about here.  Our packed .xap file sizes for the VE and OSM assemblies are 44K and 5K respectively.  Some of this is probaby even overhead from being currently in standalone assemblies.  Furthermore, XAP files will be cached by most browsers.  So relatively speaking, these TileSource files are really only a tiny amount of CIL and will have no real impact on download time. 

For a point of reference, we should all check out ComponentOne's DeepZoom mapping implementation.  They support VE & Google Maps, and have a simple interface for users to programatically add additional TileProviders if they choose.  Thier entire mapping assembly is less than 100K and is just one simple assembly.  With that in mind, I suggest we take heed of the adage, "Make things as complex as they need to be, no more".

Nov 12, 2008 at 12:24 PM
I like Rico's idea of having the main assembly contain a few standard providers and use satellite assemblies for additional providers. I'm not a fan of using an enum to switch providers because that doesn't lend itself to adding custom providers. I could get behind using inheritance (VEMap, OSMMap, etc) for easy setup if we could agree that the inherited class only adds the necessary base layers and maybe a convenience property for map style. All functionality would still live in the Map class and it could still be used instead of the inherited set of Map classes.
Nov 12, 2008 at 10:45 PM
In terms of design time support I can't see the actual map surface (MSI control) ever rendering inside Blend. Correct me if I am wrong?

I agree the control should just *work* for both developers and designers. However you will have to make a decision as to what data provider(s) you will be using. This isn't just limited to one, I could very well use 4 providers for image layers and a 5th for geocoding services. Its a powerful demo to show all the major providers running next to each other in an open source control that is richer then their own. The direction we take shouldn't limit the use of only one provider for the control.

Currently the solution requires some manual setup of dashboards, tile layers, geocoders etc. It actually offers a lot of flexibility but is harder to just run with.

When we first set out I had no idea how much code would be required for each data provider, I actually thought it would be considerable. We can now see it is very minimal and much is shared (and has been refactored and become common). For the sake of simplicity I have no issues bringing the providers into the same assembly. For ease of use haveing a single dll with some nice defaults is going to make this all much smoother.

Side note, ComponentOne is not using DeepZoom (the MSI control) (, most controls out there have rolled their own control to load tiles and as such will allows be larger in assembly size. I'm really impressed by this project, let's agree on a simple way to bring this into a more simple control for the end developers and move forward to a release in December.

I will sort out why the solution is not running out the box, you shouldn't need to re-reference the silverlight dll, very strange.

Nov 12, 2008 at 11:24 PM
Edited Nov 12, 2008 at 11:31 PM

That’s great John.  So glad we’ve come to agreement.  And you are right that we will not be able to fully render the MSI map on the designer surface.  But there is still much we can do.

I evaluated ComponentOne’s map for a while, so I am pretty familiar with it.  Actually, it does use the MSI (see thread here).  Their stuff looks pretty, but I abandoned it for this project when their  performance just wasn’t up to par.  This is my first experience with open source, and I am so far really enjoying the ability to improve things and contribute rather than being stuck with what’s available.  I am impressed by the work you’ve all done and I think this project exceeds C1’s implementation in many ways.


Nov 13, 2008 at 2:57 AM
I also looked at the C1 map control demo, and I agree the DeepEarth control is actually better and already has more :)

I lost all my stuff/work I had done on the deepearth route/find controls on my other PC

I am now remaking it again, I am in the middle of making some "wrapper" classes for alot of the webservices some GeoRss stuff :)

currently these are just in there own .dll, but I will make a demo with the map control and post it up later with a link and then you guys can decide if/how you may want to include it into the project if you want..?
Dec 10, 2008 at 3:50 PM
Edited Dec 10, 2008 at 3:54 PM
Soul.  Your fears have been realized.  My thoughts are still evolving on how to best package the data providers.  We are now up to 8 tile sources in the main project.  I agree with you not wanting to have too many in the project.  We are probably at that point now.  The current configuration served us well to make refactoring the BaseLayer classes down to their core much easier.  But now that this is complete, we need to consider final packaging, My suggestion that we place all the data sources in to a Single project.  Maybe call it DeepEarth.ProviderReference.  This could then service more as a library for developers to pick and choose the providers they want.  That way, we don't even care how big it gets.  Rarely, would anyone want to implement all of them anyway.  Thoughts?
Dec 10, 2008 at 11:38 PM
The prototype project is the exception showing everything we support. If someone is licensing VE then they are unlikely to use others but then again I can see the value in something like the openstreetmaps where its data in some areas is actually better.
Things like Google Moon seems a little off to have in the core DLL.

Lets look at some scenarios:

1) I want to visualise my data quickly and for free. I choose OSM, have a static KML file. I don't need VE, geocoding, routing.
2) I just want the complete VE services
3) I want to use my own custom WMS server only
4) I want everything and let me user choose

@Rick: Would the idea be that by putting them in a single seperate project that if a developer did want to trim the fat it would be easier to do and mantain? I could see a lot of customisation of in the Data Providers for people, eg custom tiles servers, custom routing services etc.

Simply putting everything in a another DLL reference from DeepEarth will not reduce the default size of the control, but after a quick look it seems the xaml is actually the big contrubutor to the increased size.