>If you write it, I'll use it. <s> I think it makes a lot of sense.
When I read the HTML5 specs including local sandboxed files, this was the first idea - not finding large holes in it since then.

>Bring the first <n> rows back, and asynchronously continue getting the data after that, with rules for caching, etc. This would also give local cursors to query against, just like that product Microsoft had that was some kind of animal, wasn't it?

Yupp. Sans the "autospanning" memory#disk placement of the actual data - but with the option to of a biz object to use a :memory: or disk based DB. More logic could be later added - dynamic "placement" of such a cursor should be easy.
Caching logic must work off remote and client timestamp/recordversion fields and if used together with connected internet apps might help reduce transport a lot: keep log of client cached recordversions at the server and filter all resultsets through it for unchanged timestamps...

Pro: Pure lookup tables can be installed locally or loaded at start.
Pro: Having to work with data from different backends together will be easier and local denormalizng for grids and reports can stay in pure SQL. Not necessarily a speedup compared to pure server munging, but good for busy servers.
Pro: Even the "tableupdate" logic with different SQL for some backends stays in this layer, not tainting the higher layers.
Pro: Using a buffered copycursor as biz data source gives you the needed logical isolation per definition, but still allows you to add as much object datastructure as you deem necessary for your task.
Pro: Portable down to Symbian, well tested trough many other apps.
Pro: small footprint of embedded SQLite

Contra 1: No xBase access. SQL *can* handle all fucntionality, but:
- no set relation to skip through resultsets
--- worst side effect for me, as this is a great help in finding my own mistakes in datamining and unconscious model building
--- the feature keeping me in fox currently for data exploration besides force of habit
- the xBase nicety of working on an "activerecord" must be switched to the biz layer.
---working at the dot prompt for some datamining / tryouts will be less easy / more errorprone
- scan/endscan must be moved to iterating of keylists or done in pure SQL
---sometimes it is at least for me easier to visualize in setless logic - especially if I need a log to grok it...
- lookup functionality before done with locate, seek, indexseek will have to work through a SQL Select
- no set filter and set key or similar helpers - can be delegated to the programmatic side working on the results

Contra 2: no "replication" well tested by the backend DB vendor
- can grow to be a real PITA and chance to introduce slow mechanisms

Contra 3: not as BS-Bingo compatible as ORM architecture - from a sales POV ;-))

>re: dumping Silverlight -- doing so publicly might allow them to buy Adobe, since they would not have a competitive product. I wonder if the meeting MS had with Adobe a couple of weeks ago was to see if they could do something before the Redmond PDC, but it didn't work out. They sure have come up empty, and left developers in the lurch. They are working hard to develop that reputation, as a company that leaves developers in the lurch. "Where are they going to go, anyway?" I can imagine MS management saying, having paid little attention to what is going on around them. Right now, if you are a Silverlight for the web developer, good luck getting that next enterprise (where they are about what you use as tools) contract. Meanwhile, the Java development house can pitch that IBM and Oracle are backing the Java stack, and it's not going to be going away. What a mess.

To be fair, C# is now several steps ahead of java for my taste. Additions like 3.5 automatic type discovery (the type inference of Boo IMHO is now only ahead by not needing the "var" keyword of C#), 4.0 Expando objects for vfp addproperty() or Python selfmodifiying objects, 4.0 "dynamic" as corporate speak for "duck" typing - there is progress, a difference and probably some vision<g>.
C# is more than half way similar to the capabilities of Boo when compared with java, while keeping the [wrist-unfriendly, but portable] C heritage of "{};". Java pro of multi-platform hinges a lot of the handling of the oracle-google splat - if many mobile devices fall out of the java umbrella as a side effect, that will influence TIOBE <g>. Witness: Objective-C

Any idea if Boo is targeted for JVM as well ? (You get the idea I dislike java LANGUAGE...)
[Cobra has this listed as target, but is honest enough not to put it in the near future ;-) ]
Boo having it's own "duck" type might give it a leg up to implement such things in a JVM -
Cobra *is* already a boot-strapping language, something Boo currently aims for.
And reading the thoughts if the Cobra head dev for WebAppfwk makes it clear that much of his reasoning resonates with me.

BTW: WTF is the need for 2 such similar pythonesque languages on the CLR ?
If the head people cannot come to terms and
create a version combining the strength of both (Boo Metaprogramming, Cobra Contracts)
without the weaknesses (Boo not bootstrapping, Cobra stooopid Boolean logic handling)?
This is one of the indirect reasons making the largely accepted C# easier to swallow for me.
An approach similar to Cython to hoist perf related parts out of "pure [Iron]python" via generating a
statically typed base class in C#, Boo or Cobra might make more sense than
playing only in Dotnet with a python-inspired syntax only.


Getting off to work on some web service consuming layers...

regards

thomas