Tuesday, February 26, 2008

DataObjects.Net 4.0 and Silverlight

I want to publish some info on our intention to support Silverlight in DataObjects.Net v4.0.

Facts:
-
Silverlight seems to be the future of interactive web applications. It should replace Flash in some (not very predictable, but ;) ) future. One of the greatest features of Silverlight is that it has integrated core part of .Net Framework - so Microsoft finally got a good motivation to get at least feature-limited, but portable version of it. Silverlight v1.1 alpha runs on Macs right now.
- The bad thing is that now there is quite rough information on what they're going to support. Ok, CLR... But which assemblies will be available? Silverlight installer is just ~ 4Mb, so probably there will be really quite limited set of assemblies. For now only quite brief information on it is available (btw, any help here is quite appreciated). The good thing is that they're already supporting all .Net framwork 2.0 MSIL features - i.e. generics, etc. will be working. They already declared LINQ will be integrated, that means a lot.


Let's compare this with what we have now: ok, we may expect some problems with delivering Silverlight based version of DO 4, and the
most complex of them are:

1. We use Reflection.Emit in some cases - it looks like it won't be supported. But now our code is much mode modular, i.e. this means we should provide less efficient implementation of Tuples & some generated delegates we're using. Basically, there are just several classes in Xtensive.Core (DelegateHelper type & few Tuple-related classes).

2. There is some threading-related stuff. Probably, it also will need some replacement (not sure if System.Threading will be supported).

3. Xtensive.Core.Diagnostics uses log4net & NUnit. Again, at least we can simply turn this off. Our logging is quite flexible from the point of underlying implementation - i.e. we never show log4net loggers, but use them only inside our own ones.

4. Finally, we use PostSharp. PostSharp.Public assembly is small (i.e. probably needs minimal fixes to run on Silverlight), but depends on serialization (btw, we too). So hopefully they'll support something here - otherwise we should seriously work on handling this.


Everything else seems fine. In any case, I think we should support Silverlight - new DO can play actually much more important role here: its support for non-SQL storages (i.e. a set of built-in ones, such as in-memory and in-file) seems simply what people will need: Silverlight provides access to isolated storage, where client may cache its own files. So let's provide Silverlight application with an ability to work with entities by absolutely the same way as on desktop \ server, but cache the data in memory or isolated storage - this gives an opportunity to built smart clients much easier (since they share the same BLL+DAL). An ability to synchronize storages & transparently download everything which isn't available is one more feature that may resolve lots of problems.

Finally, I really believe Silverlight is a future of interactive web (AJAX, Flash, etc. should loose in relatively short timeframe - probably, 2..5 years).

So there is simply no choice ;)

2 comments:

  1. The next version of PostSharp will be able to target other variants of the .NET framework. However, this code is still unreleased.

    I've never tried Silverlight, but it does already work with the CF.

    Major changes are support for assembly redirection in Core and pluggable serialization in Laos.

    Gael

    ReplyDelete
  2. We never tried it too, at least on DO. - should finish it for .Net first ;) But we will - as far as it start to work.

    ReplyDelete