Thank you for the post, David. I've wrestled with this thread. Clearly RC1 introduced such significant changes, that it should never have been called RC1. However, I'm glad you made the changes. You listened to the feedback on the issues with handling mouse interaction in the prior versions, and you stepped back and gave us an incredibly more powerful model... and in a short window. There is no way possible to have done all of that w/o introducing some issues.
I think the locking requirements for multi-threaded operation are probably beyond the capabilities of many developers. That is not a reflection upon their skill, but rather upon their exposure to multi-threaded applications. I've programmed since 1975, and I'm just now learning about multi-threading issues and requirements. I recommend that you ship with multi-threading set to false, by default, and that you have a pretty detailed document that defines the requirements for multi-threading use.
I have told my bosses that it will be three months before MS3 is stable for a large-scale production release. That's just my gut feeling, based upon experience with the current builds. And, that's the multi-threading version. I'm fortunate, in that I can live with that timeframe.
I could never use MS2. It was an very powerful app if you could work with shapefiles, but moving our data into the horrible shapefile format was not something we were willing to do. I'm not surprised that the extensible solution that you have built now is slower than a dedicated app with a single processing option. But what you have built with your custom layers, customer styles, etc, is exactly what I have wanted for as long as I have been programming against GIS engines (20 years). I absolutely love the ability to easily create custom layers and styles that work directly on top of my existing .Net datasets and use other theme and style constructs that I have developed over the last several years. Working with our legacy data and thems has required no data conversion to move to a .Net managed application. I really applaud your efforts on this part of your model.
We are using the work map kit, morphed into a custom layer in our app. The tile caching and zoom sets seem to really work well when sitting on top of literally hundreds of shapefiles. I do think, though, that the requirement of copying data source features into a string-based feature collection every time the map is redrawn is always going to be a problem when you try to use your off-the-shelf components and non-shapefile data sources. Where we have implemented our own custom data sources, we've ended up finding ways to build the projected feature collections one time, and always return the full collection, rather than regenerate each time on the fly. This made a big difference for our snappiness.
And, I do have one other thought. My guess is that those of us that had apps that were 70 or 80% complete are having more issues with RC1 than are those that are starting from scratch with RC1. The chances of getting through all of the code of an existing application that compiles correctly, and finding the places where the locking wrappers need to be used are probably very slim. The chances of addressing the locking in a more generic way during the early phases of building an app are probably much greater.
We are still using multi-threading... on principle. But we've conceeded to revert to single threading as we get closer to production if that stops any mysterious issues. For as long as we can design for multi-threading, though, we will, because I think it is likely a more extensible design pattern in other areas, too.
As to having purchased a license for a beta product... I'm ok with that. You have incorporated many of my requests during the 4 months my team has been licensed users. We're committed to the product, and I have no reservations about having paid for the license when you listen to my feedback.
Thanks again for listening to all of these concerns so objectively.
