More to your point Jan , if Jeff wanted to simply get a collection back from a Silverlight via a browser initiated Linq query, no go... You'd have to have Telerik create a full build for Silverlight and then runnable on the CoreCLR (the specific CLR Silverlight uses). Many dont realize it's a different world as it runs unmodified on Apple, Linux, etc. It's more a 'OS in the browser' then people realize.
So the next step of binding that result to say a Silverlight grid, and perhaps even using 2-way binding for example is obviously out.
I have not played with Microsoft;s new data API http/s (Dynamic Data I believe it is called) but that gives you the conceptual model. The browser would be calling either a literal web service or something at the same level of abstraction. The web service is where all the nice code lives for ORM. I'm a deep NHibernate guy and excited to learn more about Telerik's offering.
Most implementations in any ORM .NET project I have seen unfortunately end up as 'ActiveRecord' not ORM. In 'ActiveRecord' a mapping is made from a table to class and the class is CRUD enabled (more or less). Nothing wrong with that. It's just using a tiny piece of what ORM can do.
ORM is where there is no correlation between the two worlds except in a 'pure abstraction' of meta that has no impact on any code down or up stream (or that is the goal with vendors offering different levels of compromise).
People are using isolated storage effectively for small client-side data caching of results you get in a more raw format as described.
The problem is it's all infrastructural plumbing work, and it's done in most other scenarios.... I
If you have one specific use case in mind I'd be happy to share code. I have it all done and in production so it wouldn't take long.
You would call via the WCF SIlverlight support into a server side service which can handle all the ORM APIs you need, be they from Telerik, redhat (NHibernate), etc.
Damon Wilder Carr