JavaDB: An idea whose time has finally come?

JavaDB: An idea whose time has finally come?

Summary: Last year, at ApacheCon, according to Sun Chief Open Source Officer Simon Phipps, Sun senior staff engineer Francois Orsini apparently gave a demonstration of JavaDB -- Sun's version of Apache Derby.  Apache Derby is basically a full blown relational database management system (RDBMS) that's based on pure Java.

SHARE:
TOPICS: Software
55

Last year, at ApacheCon, according to Sun Chief Open Source Officer Simon Phipps, Sun senior staff engineer Francois Orsini apparently gave a demonstration of JavaDB -- Sun's version of Apache Derby.  Apache Derby is basically a full blown relational database management system (RDBMS) that's based on pure Java.  In other words, all it needs to run is a Java Virtual Machine.  Derby became a part of the Apache Project when IBM open sourced it in 2004.  I can easily imagine JavaDB serving as a repository for office productivity documents. The technology was original called Cloudscape and originally came to IBM by way of its acquisition of RDBMS solution provider Informix which in turn had at one point acquired a company named Cloudscape (formed as a startup by some ex-Sybase people).  IBM continues to have a version of Derby under the Cloudscape brand name.  Meanwhile, Sun's Tim Bray announced at ApacheCon that JavaDB (Sun's version of Derby) will be included in Sun's Solaris Enterprise System.

The news escaped my interest until just after a Sun roundtable that I attended concluded and Phipps, who originally blogged about JavaDB, asked me if I paid any attention to what he'd written. I had not. But, based on the look in is eyes, my spider senses told me that I probably should have.  It's taken me a while to give JavaDB a look.  But, now that I have, I'm glad I did.  I'm not sure that Orsini's aforelinked blog does JavaDB (and Derby) justice for what it is and what it's capable of.  But if I didn't know better, I'd say it could be a missing link if not the missing link in solving the number one objection to thin client computing: being able to  work offline. It could also address another problem for companies going down the handheld route; because it's based purely on Java and because there's a Java Runtime Environment for most handhelds (as well as notebooks and desktops), JavaDB offers an opportunity to standardize on one database technology across many devices (BlackBerries, Treos, Windows Mobile-based devices, etc.). 

Back to being able to work offline, for as  long as I can remember, every time I've written about the death of the fat client at the hands of the sheer elegance of thin client computing (where everything the apps, the storage, etc. is in the cloud), I've been hammered by the offline crowd.  "What happens when you're not connected to net?" They ask.  "That's why fat clients rule.  Always will."  Even my fellow ZDNet blogger George Ou refuses to throw me a bone -- taking on the role as fat-client whip every time he encounters my thin client rhetoric. 

Having inched Web-based applications several notches closer to the sort of interactivity and richness that fat client software (the software that runs on top of operating systems like Windows, OS X, and Linux) is known for, AJAX style programming has probably done more to revive the idea of thin client computing than any other recent technology fad.  But, for Web-based applications, it still doesn't solve the problem of what to do (beyond having a fat client at the ready) when there's no connection.  Using blogging as the perfect broad-based example, a lot of bloggers update their Weblogs by using the browser-based Web forms that are associated with their blogging service. With no Web server to get its Web pages, forms, and instructions from, how is a disconnected thin client supposed to work?  Because of the way JavaDB basically persists in a browser's cache without an online connection (the same way a Web page might be retrievable from browser's cache even though there's no connection), JavaDB solves a major league storage problem when it comes to working offline with structured data. 

Shortly after Orsini gave his demo, I tracked him down for some more details on the problems that JavaDB solves.  Orsini gave me the tops of the waves first; stuff that interests developers and admins like how JavaDB is SQL 92 and 2003 compliant and the database.  One of JavaDB's key features according to Orsini, is its light footprint. Java isn't exactly known for being a svelte consumer of system resources.  Throw a full-fledged database on top of that and you could see how enterprise developers might start to shy away.  But Orsini swears it's lightweight and fast and apparently showed as much at ApacheCon when the demo he did in Firefox used a small plug-in that ran on top of the Java Virtual Machine plug-in for Firefox.  That along with the fact that the brute force of Moore's Law is finally having a bit more of an impact on handhelds (with memory costs dropping and processors getting more powerful and less power consuming) could mean that JavaDB, a technology which is based on nearly 10 year old database technology, may have finally reached a tipping point. 

Of even more interest to those deploying mobile databases is how, like dyamically loaded Java apps themselves, JavaDB is easy to deploy over the air from a Web page.  There's just one Java Archival Resource (JAR) file: the file that contains all the Java classes that are necessary to get JavaDB up and running.  In his demo at ApacheCon,  Orsini showed tax filing application.  He showed how an app would automatically download as part of an HTML application, how the egine will resides securely in the local cache, and then how it all works seemlessly offline. 

This doesn't have to be about just rows and tuples of databases either (although many enterprise developers may want it for just that).  I can easily imagine JavaDB serving as a repository for office productivity documents (Microsoft Office, OpenOffice or any one of the new breed of AJAX driven offerings for which JavaDB could be perfect).  All that would be needed is some sort of software shim that makes the JavaDB look like a filesystem.  Never heard of database driven filesystems? Database technology is in fact what will run Microsoft's future file systems.

Once I realized what JavaDB was capable of, my mind start to whir a bit on the possibilities.  For example, let's say all PCs, public kiosks, and seat-back Internet terminals on the planes we fly include at bare minimum a browser, Java, support for Java Specification Request 80 (more on that in a second) and a USB port.  Now imagine that everything you normally keep on your PC (documents, contacts, etc.) is stored on a USB key that's compliant with both JavaDB and JSR 80: the Java USB API that, according to official description, "allows Java applications to discover, read, write, and manage USB devices." 

Once the browser is started, by virtue of its Java JSR 80 support, it should be able to -- within the context of the Java plug-in -- see a list of HTML pages on the USB key.  Going back to the earlier example of blogging, one of those pages might be named "Create a New Blog."  By clicking on that, a Web page is launched that presents the blog authoring form and then, in true offline fashion,  when the SAVE button is pressed (after you've written something), it calls in the JavaDB plug-in, loads the database, stores the data (replicates it from the JavaDB in cache to the one on the USB key), and gives control back to the end user for some other task.  Or, provided the receiving end were set up for it, some AJAX code can check to see if the online repository for the same data is available and just send it there.  But, when it's not,  the next time the Internet is available "to the USB key," the data in the JavaDB is replicated to the appropriate database in the cloud.  With the right scripts, JavaDB could easily multiplex to a variety of other non-native data stores (eg: TypePad for a blog, a SQL database for the enterprise, and your local contact manager).

Today, working offline is the major objection to working with AJAX-driven Web-based productivity apps.  Not so much so with real database apps because enterprise IT departments have learned to pick a strong mobile database offering like Sybase's SQL Anywhere that's preconfigured to synchronize with a mother database.  But virtually all of those offerings-- be they from Sybase, Oracle, IBM, or Microsoft-- require fairly thick and non-dynamic (in terms of the way code is loaded) clients.  Some offerings like those from Microsoft tie you to Microsoft's operating systems and, as a result, they've had to force certain client technologies on their end users.  What if you're on a platform from Palm or RIM or you're running Linux on some desktops? 

Furthermore, software developers have no motivation to turn those database technologies into file systems for storing productivity documents since, because of their limitations, they'll never be ubiquitously supported and the ROI of adding such a feature would be quite questionable. But, given it's dynamic nature,  the ubiquity of browsers,  and it's OS-agnosticism (by virtue of using a JVM), JavaDB could turn into that technology if only a few key developers prototyped the possibilities.

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

55 comments
Log in or register to join the discussion
  • That link wasn't me saying it

    Actually, I don't use the word "fat client" all that much, I prefer "rich client". Besides, rich clients are thinner on memory, CPU, and bandwidth than web clients.
    georgeou
    • If anything's fat, it's java

      http://blogs.zdnet.com/Ou/?p=199
      georgeou
      • .NET just as fat.

        .NET is just as fat. The only difference is that it's impossible to find out what resources .NET actually uses in your system.
        tero_t_vaananen@...
        • .Net at least is swift

          As you point out, .Net is just as fat as Java, and it is hard to find out what system resources it is using. But it is infinitely faster for desktop applications, in my experience.

          J.Ja
          Justin James
  • OK, I'll respond now

    >A thin client doesn't need a local
    >database if it has access to the file system

    I agree. But, why don't thin clients have access to a lightweight file system today? Given that there are multiple incompatible filesystems out there (and the royalties you have to pay for a very popular one), I'm saying JavaDB offers a unique opportunity to rethink how thin-clients get access to local data while staying pretty thin.

    >(and a DB needs that anyways)

    To the extent that JavaDB persists in a browsers cache, its needs for a filesystem are atypical. That's part of what makes it special. Filesystems have always been a problem for thin client computing.

    >and a local database does not help with
    >any of the other problems out there

    I disagree. Local databases are being very successfully used in many applications. The clients are typically a bit thick (or "rich" to satisfy George), but local databases are used in many many mobile applications.

    >not the least of which is the overall
    >suckiness of AJAX as a programming
    >methodlogy.

    Well, pick your language and you don't have to
    spit far to hit sloppy programmers. Spit a little farther though and you'll hit someone who can do mission critical stuff that gets a job done. If you're saying AJAX is useless, I think there are plenty of people out there who disagree.
    dberlind
    • <sigh>

      [i]"I agree. But, why don't thin clients have access to a lightweight file system today? Given that there are multiple incompatible filesystems out there (and the royalties you have to pay for a very popular one), I'm saying JavaDB offers a unique opportunity to rethink how thin-clients get access to local data while staying pretty thin."[/i]

      Web browsers do not get access to the local file system due to [b]security[/b] reasons. True thin clients do not get access to the local file system because their is none. That being said, there are plenty of file system choices out there (like FAT) that any OS can read and write to. Futhermore, databases are just about the worst possible method of storing many types of data, especially large binary objects (BLOBs). Any DBA with more than a week in CS 101 knows that the DB is where you store a reference to a local file system object, not the object itself, if you want BLOB data.

      [i]"To the extent that JavaDB persists in a browsers cache, its needs for a filesystem are atypical. That's part of what makes it special. Filesystems have always been a problem for thin client computing. "[/i]

      We completely agree here. Again, a database does not resolve diddly squat. Much of the "interesting" data out there is in a tree format (such as a typical HTML document), not a table format, and relational databases do not handle trees very well. Other data types (like images and other multimedia) just plain do not make sense in a relational database.

      [i]"I disagree. Local databases are being very successfully used in many applications. The clients are typically a bit thick (or "rich" to satisfy George), but local databases are used in many many mobile applications."[/i]

      How in the world does a local database address [b]these issues: http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=15011&message ?[/b] This is now at least the tenth time that I have brought up this laundry list, and you never once discuss them. These are not technical problems, these are business problems. Local databases address only technical problems.

      [i]"Well, pick your language and you don't have to spit far to hit sloppy programmers."[/i]

      Amen to that!

      [i]"Spit a little farther though and you'll hit someone who can do mission critical stuff that gets a job done."[/i]

      No disagreement here!

      [i]"If you're saying AJAX is useless, I think there are plenty of people out there who disagree."[/i]

      And they fell off the same rocker you did too when you drank the AJAX Kool Aid. Have you ever tried writing a piece of AJAX? It is extremely difficult for even the est coder to write anything that is even moderately complex. There are browser incompatabilities all over the place; blame whoever you want (browser maker of your choice), that does not change the basic fact. More importantly, the problem with JavaScript isn't just the language itself (although it is extremely weak, even as far as scripting language go), but the interpreters! I don't care if you have Donald Bloody Knuth himself writing the code, it doesn't change the fact that JavaScript interpreters are slower than molasses. Try iterating through a few thousand objects in JavaScript, which is exactly what your little JavaDB scenario will want to do. It will take literally tens, hundreds, or even THOUSANDS of times as long to execute as comparable code outside of the browser. I know. I have done it.

      Even James Gosling says that AJAX development is incredibly difficult. If you were familiar with the code writing process, you would know that writing AJAX code [b]today[/b] is comparable to writing COBOL or BASIC in 1983 in terms of the quality of the tools available. I know of no experienced coders who prefer having to write AJAX over anything else. Sure, the results may be nifty, but AJAX does not bring a single thing to the table that other techniques do not.

      And you still have not touched any of my legitimate concerns with thin client computing.

      As a few other posters have already pointed out, your vision of "Web 2.0" is just as client side heavy (George Ou convincingly argues even HEAVIER) as traditional client/server applications. AJAX requires more lines of code, has weaker libraries, etc. etc. etc. than any other programming technique out there. JavaDB does not resolve any of this.

      AJAX does not resolve a single problem that exists in traditional Web development, all it does is provide some additional functionality and convenience to the end user. At the end of the day, the Web was never designed to be an application platform, nor should it be. Let it fulfill its role, and find a better system for this type of computing.

      J.Ja
      Justin James
      • Proper link

        http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=15011&messageID=300113&start=-4
        Justin James
        • I. Hate. Your. Comment. System. ACK ACK ACK

          As I said a few days ago, if ZDNet cannot even get something basic (like posting a link right) then they have no business even thinking of telling me how to write code!

          I give up. No one there listens, or if they do, they are not able to resolve the problem. Yes, that is a challenge. Here is an opportunity to put your "outsourcing is better" money where your mouth is: pay me standard consulting fees of $250 per hour, and I will be delighted to fix your broken, unusable, unfriendly TalkBack system in a month or less.

          J.Ja
          Justin James
        • Well said, Justin!

          Thanks for going to the trouble of writing all that and posting the link here.
          PMDubuc
      • Re: <<sigh>>

        Here are my responses to some of your points:

        [i]Web browsers do not get access to the local file system due to security reasons.[/i]

        Trusted web applications (i.e. signed ones such as applets can access the file system). But I know you're aware of this...

        [i]Futhermore, databases are just about the worst possible method of storing many types of data, especially large binary objects (BLOBs). Any DBA with more than a week in CS 101 knows that the DB is where you store a reference to a local file system object, not the object itself, if you want BLOB data.[/i]

        Not everything on the client side revolves around BLOBs - we're not talking about storing blobs from what I know...and even if we wanted to, database systems can do that fairly well too - this includes providing BLOBs streaming capabilities between a client and the database engine...but again, BLOBs are not the issue here...I don't have to store a tree type of data either - it is all based on the application's requirements and the data that needs to be stored...I could even store some XML representation of some tree type of data if I wanted to...

        [i]Try iterating through a few thousand objects in JavaScript, which is exactly what your little JavaDB scenario will want to do. It will take literally tens, hundreds, or even THOUSANDS of times as long to execute as comparable code outside of the browser. I know. I have done it.[/i]

        I don't have to iterate through thousands of records via Javascript - JavaDB supports Java procedures so if I get into some performance issues, I can move the iteration part at the Java engine level and not the javascript one...

        Javascript is weak as a scripting language? I guess you are *not* talking about the Rhino engine, are you? weak in which aspects if I may ask?

        Ajax is a web development methodology - nothing else - It serves a very specific purpose and by looking at how it is being adopted by many popular applications, I fail to see how it would be useless and a possible failure - Is there room for improvement? sure there is plenty - completely agree with this but Ajax has allowed to enhance a lot of web applications out there as well as creating some next generation ones, and this fairly rapidly...as far as its complexity, well it's everyone's opinion here - I don't find it complex myself but I agree there is room for improvement, yes.
        JavaDB has nothing to do with Ajax really - it is not meant to resolve/address web 2.0 issues; it is meant to enhance "some" web applications out there by providing a lightweight and secure data storage which can be made available to these last ones, locally and directly from the client webapp. I'm all for rich clients (did not say Fat), because I have all this CPU and DISK power in my laptop or desktop which I don't mind being used to enhance my web experience - there is a lot of webapps that can't run offline (even in some degraded mode), I'm not always connected and we're still not living in some always-connected world - hence if I want to keep reading my webmail offline, I can't these days, by enhancing the webapp a bit I could read some emails offline - this is just an example of a richer webapp. Some environments have a need for (true) thin clients and I respect that, but I don't see why it shoul be the case for all environments out there...I want a choice...I want to be able to experience rich webapps.

        [i]AJAX does not resolve a single problem that exists in traditional Web development, all it does is provide some additional functionality and convenience to the end user. At the end of the day, the Web was never designed to be an application platform, nor should it be. Let it fulfill its role, and find a better system for this type of computing[/i]

        [i]"all it does is provide some additional functionality and convenience to the end user"[/i] - Yes and that's a big win alone. I know I enjoy it everyday as part of my web experience...

        [i]the Web was never designed to be an application platform..[/i] - not according to this definition:
        http://en.wikipedia.org/wiki/World_Wide_Web
        (see Basic Terms)

        "640 k ought to be enough for anyone"
        forsini
        • Of 640K, C vs. C++ and an invitation to Justin/Francois

          Ha! The 640K comment made me laugh. I just got done explaining how, when Winchester drives for IBM PC XTs went from 10MB to 30MB, I and a bunch of other of my IT colleagues wondered what the hell we'd ever need 30MB for.

          To the point about AJAX being too difficult, yah, well C was no walk in the park (thank god for C++). Neither was assembler. And if you think the language is what solves all your problems, then why are some companies issuing patches once a week?

          Finally, I think this would be a great subject and debate for a podcast that involves Justin James, Francois Orsini, and Phil Windley (who writes frequently about subjects such as AJAX and REST).

          If you're up for it, please contact me at david.berlind@cnet.com.

          Thanks.

          db
          dberlind
          • Invitation accepted

            [i]"To the point about AJAX being too difficult, yah, well C was no walk in the park (thank god for C++). Neither was assembler. And if you think the language is what solves all your problems, then why are some companies issuing patches once a week?"[/i]

            Bad programmers produce bad code, period. And poorly written code is poorly tested, debugged, and maintained code. You are correct in stating that the choice of language does not inherently imply good or bad code. But the choice of language plays a tremendously large role. A language that lends itself to hard-to-read code (Perl can be written very fast, but that quickly written code is nearly impossible to maintain/debug, as an example) naturally lends itself to poorly written code. The best language in the world, written in the best possible way, is hard to maintain/debug if the tools for that language stink.

            I'd be happy to be part of a podcast, and will send you an email shortly.

            J.Ja
            Justin James
          • Invitation accepted -- how about live, at JavaOne?

            Sorry I have been over-swamped lately but since JavaOne 2006 is around the corner, why not having a podcast over there? Also as I'm just a DB guy with who likes and uses AJAX, I have invited Dan Roberts, a real Ajaxian to join, too. Will send you an e-mail, David.
            forsini
        • Re: Re: <<sigh>>

          [i]"Not everything on the client side revolves around BLOBs - we're not talking about storing blobs from what I know...and even if we wanted to, database systems can do that fairly well too - this includes providing BLOBs streaming capabilities between a client and the database engine...but again, BLOBs are not the issue here...I don't have to store a tree type of data either - it is all based on the application's requirements and the data that needs to be stored...I could even store some XML representation of some tree type of data if I wanted to..."[/i]

          I can agree with this. But again, RDBMS's are not very good for tree structured data. And XML is the least efficient method of data storage concievable.

          [/i]"I don't have to iterate through thousands of records via Javascript - JavaDB supports Java procedures so if I get into some performance issues, I can move the iteration part at the Java engine level and not the javascript one..."[/i]

          Did I say "records"? No. I said "objects" and that is a world of difference. Iterate through the object tree of a large HTML document using JavaScript. Stick a sharp stick in your eye. Those are equivalent statements. It does not matter what you do in the backend, whether it be local with JavaDB or remote with whatever you want on the other end. JavaScript, the JavaScript interpreters, XML (misery! misery! misery!), the browser itself, that is where your slowdown in execution and pain in development come from.

          [i]"Javascript is weak as a scripting language? I guess you are *not* talking about the Rhino engine, are you? weak in which aspects if I may ask?"[/i]

          It does not matter what engine you use. JavaScript is a weak language, by the base definition of weak/strong languages (measured by language elegance). As a language, it simply cannot do too much. As another commenter pointed out (and I have said countless times in the past), I would rather be writing code in Java (and I don't like Java much to begin with), Perl, Ruby (which I view as JAPL anyways, but whatever), even bash. It is a twisted cross between the weakly typed languages and the strongly typed ones; it shares too much of Java's syntax and mannerisms to be elegant, and too many of Perl's mannerisms to be easily debugged. It is not a pleasant language to deal with on any level. If the engine makes a difference in this, then you have just eliminated the one reason to even use JavaScript, which is the fact that all major web browsers support it.

          [i]"Ajax is a web development methodology - nothing else - It serves a very specific purpose and by looking at how it is being adopted by many popular applications, I fail to see how it would be useless and a possible failure - Is there room for improvement? sure there is plenty - completely agree with this but Ajax has allowed to enhance a lot of web applications out there as well as creating some next generation ones, and this fairly rapidly...as far as its complexity, well it's everyone's opinion here - I don't find it complex myself but I agree there is room for improvement, yes."[/i]

          I have yet to encounter an AJAX Web application that could not be written in CGI, ASP, JSP, PHP, etc. Don't claim that AJAX enables new types of applications, because it doesn't. What it does do is potentially make the interface feel more "desktop application-esque." That is IT.

          [i]"not according to this definition:
          http://en.wikipedia.org/wiki/World_Wide_Web
          (see Basic Terms)"[/i]

          All you need to do tonot according to this definition:
          http://en.wikipedia.org/wiki/World_Wide_Web
          (see Basic Terms)

          Forget Wikipedia. Read RFC 2616 (HTTP). On a technical level, HTTP is just about the worst possible transport mechanism for client/server activity, which is what your vision of Web applications is.

          What you are really asking for is a method of having traditional client/server applications in which the data store is permanently residing on a central server, and the application is permanently residing on a central server with no installation needed. You want to add a method of having local storage that is transparent to the end user and capable of working even when the application is offline, or to provide local caching mechanisms to provide speed boosts for frequently accessed data. Fine. I like this idea too.

          What you really want, then, is a system like XWindows, plus has the ability to transfer some are all of the processing to the client. XWindows (as well as Citrix, VNC, Remote Desktop, etc.) type systems have the advantage now, because pushing the bytes needed to instruct the client how to draw the screen is less bandwidth intensive than pushing the data itself. My Remote Desktop connection to my home PC is faster and more responsive than most AJAX Web applications. For some reason, that strikes me as quite funny. If this system had a way off offloading the program logic to the client in a cross platform way, as needed (server overload, network down, etc.) and then resync, this does what you are really looking for.

          To think that AJAX is the only or even the best (or even a good) way of acheiving cross platform, rich client applications is just plain wrong. I would rather use a green screen than most AJAX applications. And yes, I have used a green screen.

          J.Ja
          Justin James
          • <<sigh>>

            [i]I can agree with this. But again, RDBMS's are not very good for tree structured data. And XML is the least efficient method of data storage concievable.[/i]

            Agreed and that's why I could store everything as relational entities - I could store a plain XML document if I wanted to but I did not need to.

            [i]t does not matter what engine you use. JavaScript is a weak language, by the base definition of weak/strong languages (measured by language elegance).[/i]

            I misunderstood what you were saying I guess - I thought you meant that Javascript was limited as a scripting language overall ;-) - I did not use the "weak" term as per in weakly/strongly-typed (semantics)...bug again James, Javascript has been widely adopted by the web and you can't really deny this...It's pretty much everywhere...

            [i]I have yet to encounter an AJAX Web application that could not be written in CGI, ASP, JSP, PHP, etc. Don't claim that AJAX enables new types of applications, because it doesn't. What it does do is potentially make the interface feel more "desktop application-esque." That is IT[/i]

            Sure but now tell me how many people had even heard of the XMLHttpRequest interface before Ajax exposed it - "not that many at all" - sure XMLHttpRequest is not coming from Ajax but this last one exposed it and even caused it to be ported or emulated in other web browers out there...sure you could have done it with other programming languages and technics out there but who did it? who did step up to the table? noone...Ajax has caused a lot of momentum in the developement of new kind of web applications and many people have jumped onto tat bandwagon...Am I an Ajax freak? no - am a database guy _but_ I like the positive results it has caused with some web applications am using everyday...

            [i]On a technical level, HTTP is just about the worst possible transport mechanism for client/server activity, which is what your vision of Web applications is.[/i]

            It is certainly not the most optimal one but it is the mostly used out there these days (for the web)...and if it were not doing a decent job, I guess people would be jumping up and down...and screaming for a replacement, or better yet, coming up with a substitute protocol...

            [i]What you are really asking for is a method of having traditional client/server applications in which the data store is permanently residing on a central server, and the application is permanently residing on a central server with no installation needed. You want to add a method of having local storage that is transparent to the end user and capable of working even when the application is offline, or to provide local caching mechanisms to provide speed boosts for frequently accessed data. Fine. I like this idea too.[/i]

            Precisely correct and am glad you're liking it too ;)

            [i]What you really want, then, is a system like XWindows[/i]

            So, why haven't we gone into that direction yet? What are we waiting for? ;)

            [i]To think that AJAX is the only or even the best (or even a good) way of acheiving cross platform, rich client applications is just plain wrong. I would rather use a green screen than most AJAX applications. And yes, I have used a green screen.[/i]

            Actually, AJAX is not tied up to any form of graphical/display representation (it does not have to) - It is just a methodology for Asynchronous JavaScript And XML after all...and you could even scratch the last part if you wanted to...I have used a green screen myself but this was too long ago ;)

            Cheers.
            forsini
      • Wrong model for AJAX Dev

        If you bolt AJAX onto the awkward multi-page frameworks everyone is using, yeah, it's painful. To have a fighting chance to develop AJAX apps, you need to adopt a component GUI framework, preferably server side, like Echo2 or ZK.

        That doesn't answer the larger question of why is everyone trying to turn the browser into this giant monstrosity and pretending it's not turning into a fat client.
        dkappe@...
        • Well...

          [i]That doesn't answer the larger question of why is everyone trying to turn the browser into this giant monstrosity and pretending it's not turning into a fat client.[/i]
          You have a point, although 'fat' can also mean 'richer'...

          The browser is the first target because it is a known interface to the people who browse the web. It also gives you some interesting features (i.e. XMLHttpRequest) that you can use from a scripting language, and you can expand it by installing extensions - I'm sure you know that of course, but again building an application that interacts with a web server and eventually renders HTML makes it a logical choice to build it in the browser...I know one could build a standalone application but then if one can make use of the development facilities that a web browser provides, why not - Yes, you'll potentially end-up with a fatter client browser but eh not every PC application has to run within 640K anymore ;-)
          forsini
  • File systems and databases are 2 different things...

    You may have strong arguments about specific programming technologies and methodologies but that is your own view based on your own requirements and thoughts/problematics...
    The web browser is not necessarily light anymore - in the case of firefox, that is why you are given the choice of installing extensions - this is "a choice". The way I think is in terms of what a technology will enable for me and others...Saying that Ajax sucks in not rational - Ajax is a methodology which enables new web capabilities and it does it quite well - I benefit from it everyday by using some quite known apps out there - someone has to initiate some of form of standard and Ajax's adoption has been quite great so far - why? because it's an enabling methodology - does everyone need it? nope - again this is based on requirements and what it does good for you and users benefiting from it...
    Not everyone needs a ultra-thin client, not when I'm working on my laptop or desktop - all I want is more features to ease and improve my web experience - JavaDB is a database system - it is very different from an OS file system - why? cos' it has different and additional capabilities to search for data that have relations between them - a FS has not notion of relationship between data so searches are limited in 1-dimmension - there is no intersection of data - if I want to use a local and secure (encryptable) store to host my own data then so be it - the JavaDB demo showcases how you could use some online web service to file you taxes but still keep your own private and personal data online...you don't send your data to a remote server where you have no notion of how secure it is and what's gonna happen to your private data...Everything is encapsulated as part of the application running in the web browser - it does not have to be exposed on a file system in plain-text format for instance...I can even have the database process some logic (java) internally as I interact with it - this is added-features and again this is interesting for some applications out there, may not be yours but for some others it matters...I'm personally a non-believer of thin clients in the long run - why? because the CPU, memory and storage keeps increasing and at the same time, the medium size keeps decreasing...even on smart cards, you can now store 1MB of data today and if you apply Moore's law to that how many Gigs of data don't you think we will be able to store not too long from now...
    Javascript is ubiquitous, it has been used for years and is still part of most pages you come across on the web today...using it to interact with a secure and local store to host my data is not inconceivable at all...again, it depends on your application and requirements - if you don't have the capacity for it, then fine, something else will do like the OS, but myself I would rather use a lightweight DB system onto which I can secure my data and get a free query engine and portable store, rather than coming up with my own storage format and query language...remember, the web is not just about one particular file system (type) - JavaDB (based on Apache Derby) is OS and FS agnostic...
    You can read more about its features at:
    http://developers.sun.com/prodtech/javadb/features/index.jsp
    Thanks for reading...
    forsini
    • Thanks Francois

      For jumping onto ZDNet and responding here. I know it has been a while since we spoke and I was going to track you down to see if we could get a more fleshed out response to the filesystem question. But it looks like the question found you already...

      db
      dberlind
      • Thanks for the article David and np

        Cheers.
        forsini