thanx a lot. I admit your opinion with thanx. Now tell me plz then what strategy will be better for my implementation. i have told the scenario in previous posts that i want to give some input to a web page (some web-app) by the some database from my PC (this input data will be stored by some desktop application)
On 3/21/10, Tino <[email protected]> wrote: > My 2 cents to this: > > - The Google SQLite database is Browser, Profile and Domain local. So > the path depends on everything. Change the domain? Patch changes. > Change the browser? Path changes. Change the profile (another login > or another browser's profile)? Path changes as well. This is because > of security and interlocking issues (Gears locks the database > excusively as long as the browser accesses it, so two browsers cannot > access the datbase concurrently even if you make it accessible to more > than one browser somehow. Also different Gears implementation might > change the way the database looks.) > > - If you want to create some cross platform web application with SQL > access which is able to survive the future, you cannot use Gears nor > HTML5. Gears because it will go out of business when HTML5 arrives, > and HTML5 likewise not because it is not there today and it is > doubtful, that the Web SQL Database http://dev.w3.org/html5/webdatabase/ > will become a standard supported on all platforms. (The HTML5 Web SQL > Database API is not yet a standard at all, it's not even a > recommendation, it's just a working paper with some doubtful ideas in > it. My opinion.) > > So if you just want to write some Gears application which uses SQL for > something or another, go ahead. But don't complain that a certain > feature is not supported in a timely manner by Google, please. As you > have been warned in advance. Gears is no solution. It's just a hack > for Google to be able to support something new (like offline Gmail) > before the standard has arrived in a stable manner which is widely > enough deployed such that it has become usable. > > To make it somewhat portable there really is no other good way to have > something like a locally running data container (probably some Java > application server listening on port 8080) which then is accessed via > the browser. If done properly with cross domain workers of Gears this > can be accessed from a website, too, such that you can do syncs (but > this is nothing new, JavaScript and IMG-GETs can emulate such a > communication as well) with the help of the browser (such that the app > does not need to go online itself). However this still fails on > todays smartphones due to the lack of interest of the current OS > vendors to allow owners of that phones to take full control of the > complete power of such phones (which have more CPU, RAM, Storage, > Graphics power and Internet connectivity than an average 20000$ Unix > workstation in 1990), so you cannot run such a portable application on > smartphones as well if the vendor (like Apple) denies this application > in their mobile store front. > > And on such smartphones you will be left with a certain subset of > Gears as well if Gears is supported at all. I never tried it, but I > think, that the Database API will not be supported on such phones. > > Don't get me wrong. I like Gears, I use it. And it is good that it > is there. But don't think Gears is something you can base your > business on. If you do so, you err. Gears is an gadget, an option, > something which is a nice to have, which you can use if you like, but > still it must run without, as it is likely that you somewhere must > stay without Gears. Like with FF3.6, no Gears for months. > > -Tino > > To unsubscribe from this group, send email to > gears-users+unsubscribegooglegroups.com or reply to this email with the > words "REMOVE ME" as the subject. > To unsubscribe from this group, send email to gears-users+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
