Yesterday we discussed features that must compose v4.3, and finally stopped on the following set:
- N-tier usability extensions, sample in Manual showing how to use DisconnectedState in multi-tier application. Mainly, we're going to show how to deliver query results from remote domains, merge them into the current DisconnectedState, send queries remotely with DO4, send just operation logs and so on. We're going to add a set of helpers dramatically simplifying these tasks.
- Full serialization support. Our serialization framework is currently tested mainly in "by reference" serialization mode. "By value" mode is also available, but there are almost no tests for it. So we're going to simply finish with this task. Serialization is really important feature: "by reference" mode helps to serialize query results to deliver them to remote domain, "by value" mode allows to implement such operations as Cut, Copy, Paste, Save and Load with ease.
- .NET 4.0 / VS.NET 2010 / PostSharp 2.0 - by obvious reasons. This also involves some changes in Xtensive.Core - e.g. Tuple type will be seriously refactored (we're going to get rid of code generation there). Btw, .NET 3.5 will still be supported.
The first part of this plan (N-tier and serialization) is pretty short: I hope most part of these features will be available in intermediate (v4.2.X) release. But the second is much more complex.
From this moment planned release date is confidential ;) But you can track the progress. When nearly 60-70% of work will be done, we'll announce release date.
We postponed the following features, that were listed as candidates for inclusion to v4.3:
- remote:// protocol. That's what must bring true N-tier to DO4 world. Likely, one of the most expected features now.
- Sync. One more alternative for N-tier applications.
- Security extensions. Again, many people would like to see this. But since using of some simplified security model (e.g. based on just users and roles - this can be implemented in a day or so) is almost always acceptable on initial phases, we consider this is less important when two above features.
- ActiveRecord pattern. There is a large category of customer that simply won't use the product, if this isn't implemented. So possibly, we'll bump this feature up.
- Global cache with open API, integration with Velocity and memcached. Obviously, this is one of the nicest optimizations we can implement. Btw, pretty simple. But since no one demands this from us right now, it is in the bottom of this list.
- Other providers. Candidates are: MySQL, Firebird, Sybase, DB2 and our own file system provider. We're also thinking about implementing some exotic one, that doesn't have good chances to be supported by .NET ORMs, e.g. Greenplum or Berkeley DB (yes, we can - even although there is no SQL).
So these features will form a list of candidates for v4.4.
And now, the most important part:
This week it became fully clear we must port DO4 to Silverlight: Microsoft has announced Silverlight becomes primary development platform for Windows Phone 7. So now we have very strong reason to port DO4 to Silverlight. Such features as sync, remote:// protocol and integrated storage provider can make DO4 absolutely unique there.
Btw, earlier we thought about Windows Mobile and .NET CF support, but there were too many cons - e.g. DO4 is relatively large framework, but .NET CF is designed for relatively small apps; DO4 intensively relies on runtime code generation and other features, that are simply unavailable there. So it was obvious it won't be easy to make DO4 running there. But the case we have now is way better:
- Silverlight offers most of features we need. Minor differences related to security (access to public members only, etc.) won't be an issue.
- Since UI there is based on WPF, it's almost obvious Windows Phone 7 hardware requirements are much stronger: it will require more RAM and faster CPU to run; I suspect 256MB RAM will be minimum now. So nearly 4MB of DO4 assemblies (~ 1Mb, if compressed) and additional expenses in runtime (it's really not a lightweight mapper) must not be an issue on mobile devices now.
So we're going to enter the market of development tools for both Silverlight and mobile platform. I'm even thinking about starting porting process right after v4.3 release - but the final decision isn't made yet. In any case, we definitely won't postpone this too much: it's better to be among first vendors there.
Stay tuned ;)