RIAs: Faulting &Uniquing (or Merging?) (Granite, Ajax)

Today I realized that lazy loading support for Granite Data Services is in its infacy... is more like "Partial Loading" (it will load everything not initialized, and not initialized stuff will remain "unloaded" forever).

I am thinking this leads to a pattern like this:

1. I need to work with persons, so I fetch a list of them from a remote service.
2. I choose to work with the person with id "3";
3. present the contacts of person "3". (here is the tricky stuff, all the contacts that I load have a reference to person "3", what do I do about that? do I re fetch it, creating a different object and breaking uniquing, or do I look for a way to prevent that "same but different object" in my application? )

I guess that we will need something like Faulting & Uniquing , and a Client Side EditingContext (or Client Side EntityManger)... to control data in the client side... (our own idea of LDS DataStore ?)

But... until granite has that... what could we do as a first step? it would be nice if we could "merge" a recently obtained object with one a fetched before... something like ADO.NET DataSet... (I can not believe I am writing that I miss the DataSet)

I have been thinking... a fully "AJAX" traditional JavaScript based application would have the same problems if it had a complex enough UI... but I haven't heard of anything like it, it seems that most AJAX application developers build applications so simple that they don't even care about having to write and re-write client side data manipulation code... (or... maybe those applications don't even enough client side behavior to need it?).

I guess that until Granite has his own "Data Management" the way to handle data will be... to imitate the practices of traditional AJAX applications?

(Mmmm, now with Google Gears... will we see how JavaScript based frameworks for automatic handling of DTOs and ORM start to appear everywhere? Parhaps this will revive the interest in something like SDO?)

WebBrowser + Embedded WebServer + Embedded DataBase = Google Gears

Hi!

Today I found out about a new Google project, Google Gears... a new browser plugin... that adds an SQL database and a local, only for that browser on that machine "Web Server" (oh, and an external WorkerPool for threaded asynchronous proceseses)...

So... now the that WebBrowser has an SQL database... a Worker Pool ... and a WebServer... it can run disconnected applications... you can save you emails locally... or your blog entries... or your RSS (I believe that is what google reader does)... WebApplications are now... Desktop applications... (or RIAs as they are called now).

So... now... what is the real advantage of  a RIAG (a RIA with "Google Gears") vs a Desktop App? Well, lets look at its features.. the RIAG... is slower (interpreted)... needs a plugin like Flash to do  real graphical stuff... it can't access anywhere on disk  (we could say it has its own SQL based filesystem)... therefore it is still not better for graphically intensive applications (I don't see a Photoshop or 3dStudio killer in the near future) ...  but could be a nice idea for desktop like stuff (for example a disconnected mail reader, or perhaps even a disconnected wiki). But wait... we already have disconnected mail readers...  (well, but they are not multiplatform.... mmmm... wait, Thunderbird IS multiplatform... and of course we have Java to create those multiplaform mail readers if we need to do so)... okay, but we can create a multiplatform Office like system (yes, a revolutionary idea... wait... what about OpenOffice?) and of course building an Office in a technology like JavaScript will make it really fast in standard hardware (like the very successful Java Office built by Corel a few years ago... wait... never heard of it? mmm, maybe it wasn't that successful... I wonder if that was because Java was really slow on hardware back then... )

Of course... none of that is going to stop Google Gears... people are just hypnotized with building stuff in the "web way" (even if can be done easier on the Desktop)... the way I see it.. with all this stuff, as the "thin client" of the WebBrowser becomes a "rich client" it is also gaining weight, becoming fat, becoming a fat client... so... by this logic... adding a plugin to all available browsers... it is better than a Java applet... but I can't find a logical reason for that... the new RIAs are just applications that use the browsers as the platform.... the  difference with windows applications? that there are many different browsers following the HTML/JavaScript standard, and only 1 windows (of course every browser follows the standard on its own particular way)... the difference with Java? (there isn't, but RIAs are slower... and sliced in pages... that seem to be faster to download... but in fact they consume even more bandwidth than classic fat clients with their proprietary binary protocols ), perhaps the key here is the "openness" of HTML & XML and JSON as protocols for communication (but that can also be done in Java, or in .NET & Mono)

So...  I just don't get it... what it is so great about adding a database plugin to the browser? by following this path all that we are doing is reinventing the wheel (everything that can already be done outside the browser is being re-built inside it... until RIAs become as Fat as Fat-Clients... and then someone else invents the new Thin-Client... and the story repeats again).

I guess the software industry is really, really iterative... we need to go back to an re-try stuff from the previous iteration... to realize it wasn't such a bad idea... enhance that idea... and from there, realize that the idea from 2 iterations ago, was the solution for the drawbacks of our current problems...

Swing: Dying between Silverlight & Flash?

So... Now Microsoft has Silverlight and tools like Expressions to create really good looking animations and User Interfaces... and a really small 1Mbyte plugin that works in Windows & Mac OS X...

Adobe has Flash... and Flash CS3 & Flex to create really good looking animations and User Interfaces.... and a really small around 1 Mbyte plugin... that works... well... everywhere (Windows, Mac OS X, and yes, Linux)

And Java... well... has Swing and SWT... neither of them has a a tool too easily create really good looking animations and User Interfaces... (Mattise is not bad, but it doesn't compare with Flash CS3 or Expressions), the JRE is huge, Swing and SWT have better integration with current platform UI than ever before... (but, creating really good looking UIs, like those possible with Flash & Silverlight with just the help of a designer... well.. it is just not possible)

So...the Java vs .NET war.... is now the Silverlight vs Flash war? or now we have 3 powers?

The Presentation Layer: Open Laszlo vs Flex

Hi!

So I have been evaluation several presentation layer frameworks, trying to choose one for may future applications at my new job... my boss is very interested in developing applications with a "cinematic" experience... so, the main contenders are:

• Open Laszlo 4
• Flex 2

So far, the main advantage of each one are:

Open Laszlo 4:

• OpenSource (& free both ways)
• Flash & JScript UI generation
• Cinematic user experience

Flex 2:

• Flash UI generation
• Free SDK (but AFAIK not OpenSource)
• Cinematic user experience
• UI Builder
• Interactive debugger
• Syntax Colored Editor for the Scripts
• Lots of Beginner to Advanced Tutorials
• Lots of Books
• Lots of examples with matching tutorials & books
• Cairngorm architectural framework
• E4X Support
• Based on ECMAScript 4

The main disadvantages of Laszlo are Flex strength (and viceversa):

Open Laszlo 4:

• No UI Builder
• No interactive debugger
• No syntax coloring for the scripts
• Lack of advanced tutorials online
• Lack of Books (There are only 2, one from the reviews I have read seems to be pretty much a copy of Laszlo reference documentation, and the other I think will be a really good one, but it is unfinished)
• Lack on architectural frameworks or guidance (nothing like Cairngorm is available)
• No E4X support
• Based on ECMAScript 3 (older version)

Flex 2:

1. Not OpenSource
2. DataServices are expensive (but maybe the Granite project will change that)
3. The UI Builder needs lots of RAM (1 Gbyte is recommended by Adobe)
4. The UI Builder is an Eclipse plugin (this is a personal disadvantage, because I prefer Netbeans)

I really wanted Laszlo to win this competition ( I just really like the product, the idea, and I believe competition is good for customers, so I feel that keeping Laszlo alive will be good for the future of both Laszlo & Flex consumers...) but... so far, it seems that Laszlo main advantage as an opensource project (community & books support) is just not as advanced as Flex's (no good finished Laszlo books, no list of best practices, architectural guidance or architectural framework) so, I think the winner, for me, will have to be, for now, Flex... (but I hope that next year Laszlo improves, and I hope I have the chance to use it in future projects)

My wish list for Open Laszlo 4.5:

• Lots of beginner to expert tutorials of full applications (with real world authentication & authorization & architecture best practices)
• Books, books, books!
• IDE agnostic UI Builder (something like what is available for TIBCO)
• Architectural Framework (something like Flex's Cairngorm but for Laszlo)
• J2EE Integration (something like Flex's Granite project)
• Interactive IDE integrated script debugger (even if only for Eclipse)

My wish list for Open Laszlo 5.0:

• E4X support
• ECMAScript 4 support
• Something like GWT of Echo2 but with Laszlo as the underlying infrastructure. (Java only coding)

Well, now I'll just wait and see...

Are we asking too much of WebApps?

Currently in most enterprises, if an application has to be built... it will be built as a WebApp... what do I mean with "WebApp"? well you know, its an application with an HTML User Interface, (helped with a bit of JavaScript here an there). Everybody seems to think that is the best solution for all problems (no deployment, no client platform dependency, lots of programmers that "know-how" to build this kind of applications, lower security risks (no need to have a direct connection to the database from a remote client, no need to open special ports... only the well known 80 port).

But... are web apps really such a good idea? or it is just another example of "to a hammer every problem looks like a nail"?

• You don't have to do deployment: well, that is such an advantage, no need to install, no need to update... but it has is dark side... the UI (that in most cases won't change often) has to travel with your data... and with the ever increasing need for more interactivity in the UI.. that means your really complex UI is going to travel to the client every time... 
• No client platform dependency: Great, it can run in Windows, Linux, MacOS I don't have to worry right? ... wrong! you have to worry about browser compatibility, (will it work in firefox? will it work in explorer? will it work in safari?)
• Lots of cheap programmers that "know how"... (forthcoming)
• Lower security risks... (forthcoming)