Local web application

[Lasse]

Hi,
I'm about to write a new desktop application planned golive date
2008-08-01. This application will only read from a central database,
no updates.
As it would be an advantage to use it as an 'online app' I have been
looking for options. What I had in mind was to write something whit
php, lighttp and sqlilite and bundle this together for each Laptop,
and then create a syncronising mechanism between server Mysql and
local Sqlite

But now I found Google Gears and it seems to be perfect for my
application. If anyone can answer my questions I be delighted.
1. Is it possible to write a PHP/Mysql server application and via
Google Gears use this as a local web desktop?
2. Can Google Gears syncronize between Mysql server and local Sqlite?
3. What is the status of google Gears? Ready for production?

[Lasse]

Hi,
I'm about to write a new desktop application (planned go-live
2008-08-01). This application will only read from a central database,
no updates.
As it would be an advantage to use it as an 'online app' when
connected I have been looking for options. What I had in mind was to
write something with php, lighttp and sqlilite and bundle this

together for each Laptop, and then create a syncronising mechanism

between server Mysql and local Sqlite.

But now I found Google Gears and it seems to be perfect for my
application. If anyone can answer my questions I be delighted.
1. Is it possible to write a PHP/Mysql server application and via

Google Gears use this as a 'local desktop'?

2. Can Google Gears syncronize between Mysql server and local Sqlite?

3. What is the status of Google Gears? Ready for production?

[Ben Lisbakken]

Hey Lasse --

1)  Well, sort of.  You can cache the PHP files, but it will only be cacheing the output of that PHP file, it won't enable the PHP to execute locally.  In other words, if I had a PHP script that took the parameters a=1 and b=2, and it outputs "Hello World, a + b = 3", you could cache that URL with the parameters and have the correct output for the given parameters, but you couldn't reuse the file and pass it a=3 and b=4.  Does that makes sense?

2) Yep, but there is no synchronization module built into Gears -- you have to do it yourself or use a framework (do a search in this group for syncing, you should find enough resources for this).

3)  As far as being ready for production, I would say yes.  Read Aaron's post about this to see what I mean (http://groups.google.com/group/google-gears/browse_thread/thread/e0a8841e5667abfb#)

-Ben

[Lasse]

Hi and thanks for the answers Ben.
I'm not quite sure I understand answer 1.
As I interpret it I can not write a PHP app, that can work detached.
Maybe my question is wrong.
The application should help sales persons to select accessories for
tools at customers.
The is a small database with about 10 tables less that 10000 rows in
total, most of the rows less than 100bytes.
I also would like to have photos and thumbnails for all parts, but I
have not figured out where and how to store them yet.

What Language(s) can I use to create such an application that with the
help of Google Gears can work detached?
I really want to avoid installing software on each workstation, and it
looks like Gears can help me with that.

I also prefer PHP since I know the language. Can Gears help caching
the PHP code if I install PHP on the workstations.

I understand if this is confusing, but I'm confused. I thought I knew
how to build the app, but then I found Gears.
It looks ideal for what I want to do, so my question should maybe be:
Can you recommend a language to create a 'local web application'
running under Gears? Javascript?

On May 5, 8:18 pm, "Ben Lisbakken" <lisba...@google.com> wrote:
> Hey Lasse --
>
> 1)  Well, sort of.  You can cache the PHP files, but it will only be
> cacheing the output of that PHP file, it won't enable the PHP to execute
> locally.  In other words, if I had a PHP script that took the parameters a=1
> and b=2, and it outputs "Hello World, a + b = 3", you could cache that URL
> with the parameters and have the correct output for the given parameters,
> but you couldn't reuse the file and pass it a=3 and b=4.  Does that makes
> sense?
>
> 2) Yep, but there is no synchronization module built into Gears -- you have
> to do it yourself or use a framework (do a search in this group for syncing,
> you should find enough resources for this).
>
> 3)  As far as being ready for production, I would say yes.  Read Aaron's

> post about this to see what I mean (http://groups.google.com/group/google-gears/browse_thread/thread/e0a8...
> )
>
> -Ben
>
> On Mon, May 5, 2008 at 5:00 AM, Lasse <lars.a.johans...@se.atlascopco.com>

[Ben Lisbakken]

Lasse --

For me, it is usually easiest to write the bulk of my code in JavaScript and only use PHP (or your server-side language of choice) for the purpose of accessing MySQL or doing a cross-domain request.  A really great demo to check out is Pamela Fox's Blog.Gears demo (http://gdata-javascript-client.googlecode.com/svn/trunk/samples/blogger/bloggears/bloggears.html).

But before I go any further, let me clarify what you are trying to do.  You want to write your application such that it works completely offline.  So that after the first time a user goes to your site, it will synchronize all of the database to the user, as well as the JavaScript, HTML, CSS, and images, too.

Sorry for confusing you in the previous post.

-Ben

[Lasse]

Hi,
Thanks for your answers!
Yes, that's right after the first login I like to syncronise all, so
the user can work completely offline if not connected to our intranet.
When the user is connected to the intranet, everything should be
syncronised. This can be done manually or automatically.
I have never written a web-app before, but I'm a very experienced
programmer and oddly enough used PHP extensively for bash shell
programming!
Having said that I think I understand the basics of web development,
and I'm a fast learner, so I'm willing to learn almost any language to
make it fit within Gears.
I prefer PHP for this project.
I like the concept of Gears and I really would like to give it a spin.
I really really appreciate if you can point me the right direction.
The user platform for my sales app will be Windows xp/vista and
Internet explorer. If it will work under Windows mobile it's a great
bonus.

P.S. Ben you are very clear, not confusing at all. The problem is I do
not understand this area well yet.

On May 6, 4:45 pm, "Ben Lisbakken" <lisba...@google.com> wrote:
> Lasse --
>
> For me, it is usually easiest to write the bulk of my code in JavaScript and
> only use PHP (or your server-side language of choice) for the purpose of
> accessing MySQL or doing a cross-domain request.  A really great demo to

> check out is Pamela Fox's Blog.Gears demo (http://gdata-javascript-client.googlecode.com/svn/trunk/samples/blogg...
> ).

>
> But before I go any further, let me clarify what you are trying to do.  You
> want to write your application such that it works completely offline.  So
> that after the first time a user goes to your site, it will synchronize all
> of the database to the user, as well as the JavaScript, HTML, CSS, and
> images, too.
>
> Sorry for confusing you in the previous post.
>
> -Ben
>

> On Tue, May 6, 2008 at 12:47 AM, Lasse <lars.a.johans...@se.atlascopco.com>

[Ben Lisbakken]

Before I start, let me just say that this is the way I would go about doing this.  It's not necessarily the perfect or best way ;)

I would write the whole application in JavaScript (btw, you can only use Gears in JavaScript) and use PHP for any interaction with the remote MySQL database.

Write a PHP script that takes as input a date/time, then grabs all records in the MySQL database that are newer than this date/time and returns them as a CSV.  This will serve two purposes: when a client does a first-time sync, it will send them back all of the records in the DB, and the second purpose will be so that when a client wants to see if there are new records, it can say "the last time I got records from the remote DB was date/time xxxx and I need all records that have been created/updated after this time."  Since you have a fair sized database, I would consider setting the number of records returned in a CSV, so that on an initial sync, the JavaScript doesn't have to download 10,000 in one AJAX request.  Maybe you could make a mechanism so that your JavaScript asks for 500 records at a time.

Then, on retrieving a CSV, your JavaScript will parse the results and insert them into the Gears database.  Also, don't forget that if two users can edit the same row in your database then you are going to have to do some merge checking because one user could have it stored locally, change it, but then another user could have changed it and sent those changes to the remote database already.  So who's version is right?  Up to you to decide in those cases :)

In your Gears database, you will want to have a field for every row that designates whether the row has been "sync'd" to the remote database since the last synchronization.  With this field, when you decide it's time to sync, you can see which rows need to be sent to another PHP that will put them into the MySQL database.

For the syncing model, I'd follow in Pamela Fox's footsteps and assume that the client is always offline, and check every x seconds to see if they have internet.  If they do, see if you need to send any updates to your PHP, and see if there are any updates in the remote DB that need to be sent to the client.  I think you can steal a lot of her JavaScript logic.

Your program should work great on Windows + IE, and the Gears logic will be fine on Windows mobile.  However, be aware that Windows Mobile won't always behave perfectly with JavaScript that works on regular web browsers... if you really want it to work on Windows Mobile you should test that your JavaScript is working on your WinMo device as you code.

I'm sure this sounds like a lot to think about.  I think the first step for you would be to get your hands dirty with JavaScript.  Look up how to do AJAX requests (an HTTP request that happens in the background and doesn't refresh the page), start learning how to manipulate the browser's DOM (document object model... an object oriented model for webpages.  It lets you grab parts of the page and change them etc.).  Those are the two unique things that you need to learn that won't be familiar.

-Ben

[Lasse]

Hi Ben.
This looks like a complete prescription for an application!
It looks a bit complicated but that just makes it more fun to work out
the details.
My database sync will be easier than you outline, the users will not
update their
local replica so db sync is one way.
Now I only have to persuade the 'application owner' this is the way to
go.
With a bit of luck I start develop in a couple of weeks. When (not if)
I find myself in the
middle of the creek looking for a paddle I come back with more
questions.
This leads to my last questions. More documentation.
What other good sources of doc can you advise?
I'm particularly fond of books. Have you written a book on Gears?

Thanx Ben, you been most helpful.

> On Tue, May 6, 2008 at 11:10 PM, Lasse <lars.a.johans...@se.atlascopco.com>

[Ben Lisbakken]

Neither myself nor anyone else on the Gears team has written a book.  However, I just discovered (thanks to your inquiry) that there actually is a book out on Gears (http://www.amazon.com/Introduction-Google-Gears-Applications-Components/dp/047025873X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1210225635&sr=8-1).  I haven't read it, nor have I heard anything about it, but maybe you could be the first to let us know!

As far as documentation, I would go through every link here (http://code.google.com/apis/gears/design.html).  For you, I would focus on ManagedResourceStore and Database, as those are the two modules you will need.

I know it all sounds complicated, but once you dive in it won't be as bad as you think.  Pamela is experienced in JavaScript and she wrote Blog.Gears in 5 days.  I expect it will take you a bit more time since you have to ramp up on JavaScript first, but your application requirements mirror what was done in Blog.Gears.  The only difference is that her "remote database" is the Blogger JavaScript API, whereas your remote database will MySQL accessed through PHP.

Anyways, I'm excited to see how your application comes out.  Good luck, please drop us a line if you need any help.

Oh, and my last parting advice -- do yourself a _huge_ favor and get Firebug for JavaScript debugging.  I wrote a tutorial for it here (http://code.google.com/support/bin/answer.py?answer=94630&topic=11530).

-Ben

[Lasse]

Hi,
Now I got an accept for developing "Sales tool for torque arms" with
Gears!
However my Boss made it very clear I have no time for "Web gadgets",
"go back to your desk, there are many stimulating SAP issues to deal
with".
But I managed to hire my sons friend Andreas for this project, he is
now system architect and lead developer, that is when school ends.
He starts in the beginning of june. I still hang on as project
assistant.

On May 8, 7:57 am, "Ben Lisbakken" <lisba...@google.com> wrote:
> Neither myself nor anyone else on the Gears team has written a book.
> However, I just discovered (thanks to your inquiry) that there actually is a

> book out on Gears (http://www.amazon.com/Introduction-Google-Gears-Applications-Componen...).

> I haven't read it, nor have I heard anything about it, but maybe you could
> be the first to let us know!
>
> As far as documentation, I would go through every link here (http://code.google.com/apis/gears/design.html).  For you, I would focus on
> ManagedResourceStore and Database, as those are the two modules you will
> need.
>
> I know it all sounds complicated, but once you dive in it won't be as bad as
> you think.  Pamela is experienced in JavaScript and she wrote Blog.Gears in
> 5 days.  I expect it will take you a bit more time since you have to ramp up
> on JavaScript first, but your application requirements mirror what was done
> in Blog.Gears.  The only difference is that her "remote database" is the
> Blogger JavaScript API, whereas your remote database will MySQL accessed
> through PHP.
>
> Anyways, I'm excited to see how your application comes out.  Good luck,
> please drop us a line if you need any help.
>
> Oh, and my last parting advice -- do yourself a _huge_ favor and get Firebug
> for JavaScript debugging.  I wrote a tutorial for it here (http://code.google.com/support/bin/answer.py?answer=94630&topic=11530).
>
> -Ben
>

> On Wed, May 7, 2008 at 10:43 PM, Lasse <lars.a.johans...@se.atlascopco.com>

> ...
>
> read more »

[Ben Lisbakken]

Lasse --

That's great news :) I look forward to hearing from you guys when you begin work.

-Ben

[Lasse]

Hi again,
Now we started work on "Sales tool for torque arms" application!
It seems like Gears is picking up momentum.
Anyway there is more activity in this forum now than it was in
beginning of May,
and that is a good sign :-)

On May 14, 5:02 pm, "Ben Lisbakken" <lisba...@google.com> wrote:
> Lasse --
>

> That's great news :) I look forward to hearing from you guys when you begin
> work.
>
> -Ben
>

> On Wed, May 14, 2008 at 4:48 AM, Lasse <lars.a.johans...@se.atlascopco.com>

> ...
>
> read more »

[Lasse]

Hi again,
Some weeks into the project 'TorqueArm Configurator', we (i.e.
Andreas)
have come a long way. Gears is up and running, the db sync engine is
written using geers worker pools, install procedures with our own icon
on the user desktop is almost there and vs 0.3 alpha of the
application for Firefox and IE7 is kicking. There is a hell of lot of
things still to do, next thing is the photo archive, there are about
1000 photos and thumbnails of torquearm assemblies.

Andreas also has some questions:
1. We have a PHP-script generating the manifest file. One of the
reasons for this is that we will have a rather dynamic, large library
of product images.When we remove files from the image-directory the
PHP-script will no longer output them in the manifest. What will
happen to the corresponding files on the client computer? Will Gears
automatically delete the files that no longer exists in the manifest?
Of course the manifest version will be updated.

2. Eventually our application is meant to exist on quite a few of our
salesmen's computers. The applications internal updates are not an
issue - this is done with our own database synchronization model and
the Gears manifest-file. However, if I understood things correctly,
Gears may automatically update itself. Is there anyway we can prevent
this automatic update? Do we actually need to prevent this, or can we
rest assure that future updates of the Gears-beta plugin will remain
compatible? In case of any incompatible updates, will Gears
automatically NOT update itself?

p.s.

Relying on sqlite default auto-commit in the db sync engine can be
devasting for performance. We found some topics on this in this forum.
But it took Andreas some time to find and fix this. You should
consider to write something about this in the user guide.

> ...
>
> läs mer »- Dölj citerad text -
>
> - Visa citerad text -

[Ben Lisbakken]

Hey Lasse --

It's great to hear that things are going well.

For your questions, the first answer is that yes, if you take files out of your manifest then those files will be deleted on the clients the next time they sync.

For your second question, checkout this post here:
http://groups.google.com/group/gears-users/browse_thread/thread/e0a8841e5667abfb/

I think there might be ways to hack the plugin to not auto-update, but we really discourage it.  It's bad for a number of reasons.  However, if you read that post you will see Aaron explain how seriously we take backwards compatibility.  So hopefully our commitment to you guys running is enough :)

We look forward to seeing your final project!

Sincerely,
Ben

[Chris Prince]

> can we rest assure that future updates of the Gears-beta plugin
> will remain compatible?

Yes, you can rest assured Gears will remain compatible. We take
backward compatibility very seriously, and we don't want to break any
existing applications. :)

[AndreasRL]

Ben and Chris (and Aaron),

Thankyou for your quick responses and good news. The application is
still very much an alpha-version, but we're looking forward to start
testing it on end-users in a couple of weeks. It's very comforting to
know that you guys are constantly pulling your hair out to ease the
pain on us who worry about future updates :)

I have yet another question, about the LocalServer. Will it continue
ongoing processes/updates even if the client leaves my site? I’m
thinking about this large image library we mentioned earlier. If the
LocalServer / ManagedResourceStore can perform downloads only when the
user is on my site there’s going to be a pretty long wait for the end-
user during the installation. ~1000 images will obviously take a while
to download and the client wants his application offline-compatible
after the first installation.

Is it correct that I will have to ask the user not to leave my site,
or close the browser, until I say the manifest-downloads are OK?

If not - what happens with a canceled download-process. Will Gears
keep downloaded files and continue from there, or will it start over
again until all downloads complete?

And also, if the above is true - will Gears continue downloading from
where it was within a file, or will it download the whole file again
if it was interrupted?

Thanks again for your time and for your development of this amazing
plugin!

Best regards,
Andreas Röine Larsson a.k.a "system architect and lead developer"


Ps. Here are a few screenshots and graphics if you are interested!

Application draft 0.1
http://rs176gc2.rapidshare.com/files/128572764/1423091/torquearm_configurator_v01draft.jpg

Application draft 0.2
http://rs176l34.rapidshare.com/files/128572767/1423169/the_ac_way.jpg

Sample assembly
http://rs176tl2.rapidshare.com/files/128572766/1423136/torquearm_configurator_assembly.jpg

Icon draft
http://rs176l3.rapidshare.com/files/128572765/1423120/torquearm_configurator_icon.jpg

Ds.

[Ben Lisbakken]

Andreas --

I took a look at the screenshots -- it's looking like it is coming along quite nicely :)

You are correct in assuming that the users must stay at the current page to download the resources.  And for now, we don't have anything in the works to support off-the-page resource grabbing.

As for your questions about canceling in the middle, I am not sure on the details.  Michael Nordman is the creator of LocalServer, so I think he could answer this question best.

-Ben

On Thu, Jul 10, 2008 at 3:02 AM, AndreasRL <in...@visualizewithclarity.com> wrote:

(Better links)
Application draft 0.1
http://i35.tinypic.com/30hvtqv.jpg

Application draft 0.2
http://i33.tinypic.com/2hmfxvb.jpg

Sample assembly
http://i35.tinypic.com/xdvyqe.jpg

Icon draft
http://i38.tinypic.com/el43k8.jpg

[Michael Nordman]

On Thu, Jul 10, 2008 at 10:04 AM, Ben Lisbakken <lisb...@google.com> wrote:

Andreas --

I took a look at the screenshots -- it's looking like it is coming along quite nicely :)

You are correct in assuming that the users must stay at the current page to download the resources.  And for now, we don't have anything in the works to support off-the-page resource grabbing.

Managed resource stores will update in the background in the absence of a page that initiates an update. There are two ways that updates are initiated, by explicitly calling checkForUpdate(), and automatically when resources in the store are accessed via http(s) urls.  Once initiated, they run to completion (or the browser exits).

As for your questions about canceling in the middle, I am not sure on the details.  Michael Nordman is the creator of LocalServer, so I think he could answer this question best.

Partial updates will be resumed where they left off the next time an update task runs. Until the first complete version is downloaded and in use, you need to explicitly call checkForUpdate() to get it going again. Since nothing will be served out of the incomplete store, nothing will trigger the automatic checkForUpdate().
 

[Lasse]

Hi again,
This is great! Now we have a few enthusiastic beta testers.
I was browsing this thread and we have come a long way. Reading my
initial question, and realizing Andreas started the 17 of june.
He barely knew about JS and OO programming! Apart from Gears he
utilize JQuery and Highslide JS.
If you are not impressed by this, he did the lot, from design of
desktop Icon to the database sync engine and lots of image processing.
Still not impressed? I invite you to the big enterprise world, just
sit with the market communications department and have your design
standardised in the middle of the vacation period, that alone is
nothing for the faint-hearted. Not many corporate organizations would
pull this off in this time frame no matter what resources they put in.
(To be fair standardized design is very important and market comms
were very helpful)
Now this is an offline desktop app, where we use Gears mainly for the
tedious install and update. Those of you who written a desktop app
know that the hard part is install, update & delivery. Andreas not
only wrote the app from scratch but also delivered it to 5 users in
Sweden,Germany & Spain. Next are two US install, if that goes well we
are ready for production. There are about 500 potential users
worldwide of those about 20 in USA.
We already got demands from the beta testers to online integrate our
app with our Web shop https://connect.atlascopco.com/ConnectSite/account/enter.asp.
We are very happy having Gears backing us up. How fun would it be with
a conventional desktop app written in C++# or Excel macros, when the
first thing the beta testers ask for are 'I also want this online'?
Unfortunately all is not well, Andreas is one of two 'summerkids' who
made the app, the other Frida is projectleader. Andreas & Frida are
leaving in a few weeks, Frida is going back to school and Andreas to
unemployment! I'm desperatly shouting 'employ the guy' but still no
one is paying attention. I'm not worried for him, but for me and the
company.
I have realised this thread can be used as part of the documentation.
I hope it will stay alive until we go into production.
At last a question. Is there a target date for Gears 0.4? I believe
the files I/O can help us integrate our app with other, and I want
Gears toasters for its coolness, (we have toasters but only inside the
browser).

[Chris Prince]

> At last a question. Is there a target date for Gears 0.4? I believe
> the files I/O can help us integrate our app with other, and I want
> Gears toasters for its coolness, (we have toasters but only inside the
> browser).

Probably before the end of August.

[AndreasRL]

Well Lars isn't very shy about the project... He's been very helpful
though.

I'm about to release version 0.3 to the beta-testers soon, so I'll be
ahead of you guys shortly :) Gears has made the development of this
application truly interesting and educative.

I've just spent about an hour looking for a bug that just wasn't there
no matter how hard I looked. Suddenly I got errors with the worker.
Finally I came to the conclusion that some non-standard (english)
characters are NOT allowed in the worker, even if it's within a
comment. Here's my first lines in the worker, just a comment:

[code]
/**
* @fileOverview This file is a Gears Worker, called by the
synchronization process to handle
* heavy database processing.
*
* @see syncDb
* @requires gears
* @author Andreas Röine Larsson
* @version 0.1
*/
[/code]

See the Ö in my last name? Once changed to a regular O the worker was
happy again. Perhaps this is something you may want to look into even
if it's not much of a problem. Pretty hard to spot though.

Also, some of our beta-testers have had problems installing Gears due
to proxy-issues. I haven't had time to find a workaround yet, but I
know this is a known issue with the Gears-installer. I'm hoping this
will be at least partly solved in Gears 0.4.

During the development I've been thinking of a Gears-feature I'd like
to have - implemented OS network-state detection. If you unplug a
network cable, the OS will immediately tell you that. Same the other
way around of course. I know this does not mean you're "ready-to-go"
with the synchronization, but at least it could probably have the sync-
process initiate quicker if it could start trying when
Gears.onNetworkStateChange, and not having to wait for a certain timer
to call it.

When there is time I could probably detach the application from our
internal network and release a stand-alone demo if you guys are
interested!

Best regards,
Andreas Röine Larsson

Developer & System architect
Atlas Copco Tools and Assembly Systems

[AndreasRL]

I'm sorry about the double-post but something came to my mind, and I
thought I'd ask for your qualified opinion (in case of time to reply).

The image library we optionally let the users cache will be about 20
MB. In it's current state the application uses only one
ManagedResourceStore to handle all static resources along with these
image-files (looped out into the manifest from a database, if they're
requested). The LocalStore.onprocess and the database-synchronization
process is combined into one overall sync-process. On our intranet
this synchronization will take about 20 seconds, which is not a
problem.

Some of our global clients have reported synctimes of nearly 8
minutes. However, this is only the case when downloading all files
which does not happen too often since the files/manifest doesn't
change too often.

I've considered using two ManagedResourceStores, one which will handle
the image-library only. Perhaps there are other, better solutions.
What do you guys think would be the best approach for a situation like
this?

[Ben Lisbakken]

Hey Andreas --

I couldn't reproduce your problems with WorkerPool.  Though I had an ö in the comments, it still worked properly.  Do you have a link to a page that reproduces the bug consistently?

As for your ManagedResourceStore question, I guess it depends on your goals and what you are doing right now.  I don't know what kind of a benefit you'll get from having two separate ManagedResourceStores, other than that you can let the users pick whether they want to sync all of the images or to just have the application files sync'd.  Maybe it's easier for you to manage two separate manifests?  I think I would personally go with one just because the code would be cleaner.

-Ben

[Michael Nordman]

The umlaut'ed character problem has to do with character set encodings. Gears only works with UTF8 encoded script-files and textual HTTP request responses at this time.

[AndreasRL]

Ben and Michael,

I suppose my issue with the worker has to do with character set
encoding, as Michael suggests. I'm not using UTF-8 but ISO-8859-1.

Regarding the ManagedResourceStore. The manifest today is a PHP-
script, that loops out files from the servers. I use the querystring
to tell the manifest whether I want images or not, like manifest.php?
images=0. The PHP-file has a $version-variable, and the script adds a
0 if images aren't used. If images are used, it will add the last
modification timestamp of the latest modified image, like this:

<?php
$version = "1.1";
$lastMod = filemtime($newestPictureSrc);
$version .= '_' . $lastMod;
?>

I let the user decide whether or not to store images locally, and I
store their preference in the local SQLite database. This value is
then used when setting the manifest URL. The problem with having only
one manifest is that Gears has to download all core-files and all
images in the manifest (~20mb), even if I only made a slight
adjustment in one of my JS-files.

I think having the images and core-files separated in two different
manifests would be more convenient, because it wouldn't be too much of
a disaster if the client should cancel downloading of the images (due
to long download time). The core-files (scripts etc) would be in it's
own, much smaller, manifest, so they would be instantly updated on
manifest-version change.

That's just what I'm thinking right now, but I'm not sure about
anything so I'd be happy to receive further thoughts on this. Thanks
again for a great job with the Gears-plugin.

Best regards,
Andreas Röine Larsson

Developer & System Architect

[AndreasRL]

Hi,

Double-posting again, sorry about that.

After a discussion here: http://groups.google.com/group/gears-users/browse_thread/thread/352d564370c9502e
I have learned that there is no need for me to reconsider my current
application model with the one and only ManagedResourceStore. My files
were previously very small so I assumed Gears actually downloaded the
files when it was really just checking their last-modification
timestamp (which actually takes a while with 500+ files).

I'm sorry for all the confusion, and mostly I'm sorry for all the time
I spent thinking about this unnecessarily. :)

[Ben Lisbakken]

We're happy to hear you've got it figured out :)

-Ben

[Lasse]

Hi all,
This is my last post on a local web application.
Yesterday Torque Arms Configurator 1.0.0 was demonstrated at ‘Business
Area Industrial Technique General Industry’ Business Board.
The demo was a great success. After the meeting Andreas was presented
as the ‘wonderkid’ who made TaC. And we may have an order for a clone
of TaC.
Based on the experience of developing TaC I will write an internal
paper “A web browser platform for the Salesman’s IT portfolio”.
I see TaC as much more than just one application, with Gears we can
truly extend the web to the desktop or vice versa, something I wanted
to for a long time.

I have tried to persuade Andreas to write about his experience of the
development of TaC to share with others. But he is very modest and shy
about his work. “ I’m just a newbie, this is nothing, anyone could
have done it, my code is not good enough to show, etc “. I think
that’s beside the point. I do not think many have written applications
like TaC, and that Andreas experience is worth to share. Just being
dragged out of school into the enterprise world, leading the
development of an application without any experience and knowledge,
cherished as the ‘wonderkid’ and then eventually kicked out to
unemployment. That’s a story worth being told.

Anyway, thank you very much for Gears and support, especially Ben for
your help in the beginning, without your fast friendly response to my
initial questions I would have looked else were.

[Lasse]

Hi all,
This is my last post on a local web application. (This is the 2nd
submit, please remove this if the 1st made it)

your help in the beginning, without your fast and friendly responses

[Ben Lisbakken]

On Fri, Aug 22, 2008 at 10:57 PM, Lasse <lars.a.j...@se.atlascopco.com> wrote:

Hi all,
This is my last post on a local web application.
Yesterday Torque Arms Configurator 1.0.0 was demonstrated at 'Business
Area Industrial Technique General Industry' Business Board.
The demo was a great success. After the meeting Andreas was presented
as the 'wonderkid' who made TaC. And we may have an order for a clone
of TaC.

Wow, this is great news!  Congratulations to you and Andreas.  If possible, you really should share a link with us so that we can see the final product.
 

Based on the experience of developing TaC I will write an internal
paper "A web browser platform for the Salesman's  IT portfolio".
I see TaC as much more than just one application, with Gears we can
truly extend the web to the desktop or vice versa, something I wanted
to for a long time.

It's exciting stuff, isn't it?  And it's only getting cooler with fun stuff like blobs, geolocation etc.
 

I have tried to persuade Andreas to write about his experience of the
development of TaC to share with others. But he is very modest and shy
about his work. " I'm  just a newbie, this is nothing, anyone could
have done it, my code is not good enough to show,  etc ".  I think
that's beside the point. I do not think many have written applications
like TaC, and that Andreas experience is worth to share. Just being
dragged out of school into the enterprise world, leading the
development of an application without any experience and knowledge,
cherished as the 'wonderkid' and then eventually kicked out to
unemployment. That's a story worth being told.

I'm sure his code is a lot better than he thinks :)  Andreas should give some feedback on using Gears

Anyway, thank you very much for Gears and support, especially Ben for
your help in the beginning, without your fast friendly response to my
initial questions I would have looked else were.

Of course... it's been fun seeing periodic e-mails with the progress of development.

Best of luck to you guys,
Ben

[AndreasRL]

Dear Gears users and developers,

Torque Arm Wizard arised from the beta-swamp a few weeks ago now, and
my work here is nearly done. Working with Gears has been very
interesting, I'm sure this is quite a realistic glimpse of what the
future in web development will look like. Gears provides access to
functions that greatly reduces the possibility-differencies between
regular desktop applications and web 2.0 applications.

Not to mention how easy it is! The API provided is really intuitive
and easy to handle, and I'm not an experienced JavaScript developer at
all - in fact this was my first JavaScript job.

As Torque Arm Wizard runs on the company's intranet there's no way I
can publish the production version. However, me and Lars have managed
to get an Internet-accessible demo-version running. The server is an
old laptop IBM ThinkPad T23 (!!!) that sits on the living room floor,
so don't expect any amazing response times! Any comments about the
code, language, design... anything, are very welcome.

http://tawdemo.no-ip.org

Best regards

Andreas Röine Larsson
Developer & System Architect

andreas.ro...@gmail.com

[Michael Nordman]

Andreas,

Congrats to you on shipping something and thank you for the kinds words directed at Gears.

"We work for you"... nice!

Michael

Gears Hacker