Actually, I would love the ability to have my site offline synched easily to my site online. There aren't a lot of hotspots in my town, especially at the places that have kiddie stuff to keep my son entertained. I made a local copy of my site, but it's a PITA to keep it updated so I usually don't bother. Something like what has been talked about here would be awesome. Not something I'm in a position to help create, though, so it's just a wish on my part. Michelle On 5/31/2007 7:16:58 AM, Robin Monks (robin@civicspacelabs.org) wrote:
The weird thing is, with the dawn of cheap broadband, and wifi-covered cities, planes, trains and buses, noone is actually offline to enjoy this now.
Robin
On 5/31/07, Victor Kane <victorkane@gmail.com> wrote:
well, one possibility is php gtk, see http://gtk.php.net/ (there is a data persistence layer in gears) But I
wasn't speaking only of using Gears itself, but rather of the
paradigm shift to rich clients, with offline support. On the one hand stuff like Apollo, on the other ... if we have Drupal on a stick, we can have Drupal on a rich client. The paradigm shift of web apps recycled as rich client apps can be seen on many fronts, for example in the world of light, agile J2EE, the Spring Framework has the Rich Client sub-project (see http://www.springframework.org/spring-rcp).
Victor Kane http://awebfactory.com.ar
On 5/31/07, adrian rossouw <adrian@bryght.com> wrote:
On 31 May 2007, at 11:05 AM, Victor Kane wrote:
use case is manage content, prepare a new edition of a site all ready to synchronize with on line edition...
Theoretically, a way to "sync" Drupal site instances (Google Gears aside) would be awesome. Practically, it is a very hard problem to solve since most Drupal sites are in constant flux "in the wild" and therefor, once you "copy" a local version of the site and make changes, you have two separate branches with many potential opportunities for collision. You can handle some sync collisions intelligently but there will always be weird cases. Also, I can't even begin to imagine how much more effort it would take to build modules that can handle a sync framework. That said, if there were a reasonably reliable and functional tool for "syncing up" two sites forked from the same parent copy, it could lay a nice foundation for a better staged development process for large, active sites. Scott On 5/31/07, Michelle Cox <mcox@charter.net> wrote:
Actually, I would love the ability to have my site offline synched easily to my site online. There aren't a lot of hotspots in my town, especially at the places that have kiddie stuff to keep my son entertained. I made a local copy of my site, but it's a PITA to keep it updated so I usually don't bother. Something like what has been talked about here would be awesome. Not something I'm in a position to help create, though, so it's just a wish on my part.
Michelle
On 5/31/2007 7:16:58 AM, Robin Monks (robin@civicspacelabs.org) wrote:
The weird thing is, with the dawn of cheap broadband, and wifi-covered cities, planes, trains and buses, noone is actually offline to enjoy this now.
Robin
On 5/31/07, Victor Kane <victorkane@gmail.com> wrote:
well, one possibility is php gtk, see http://gtk.php.net/ (there is a data persistence layer in gears) But I
wasn't speaking only of using Gears itself, but rather of the
paradigm shift to rich clients, with offline support. On the one hand stuff like Apollo, on the other ... if we have Drupal on a stick, we can have Drupal on a rich client. The paradigm shift of web apps recycled as rich client apps can be seen on many fronts, for example in the world of light, agile J2EE, the Spring Framework has the Rich Client sub-project (see http://www.springframework.org/spring-rcp).
Victor Kane http://awebfactory.com.ar
On 5/31/07, adrian rossouw <adrian@bryght.com> wrote:
On 31 May 2007, at 11:05 AM, Victor Kane wrote:
use case is manage content, prepare a new edition of a site all ready to synchronize with on line edition...
On Fri, 2007-06-01 at 10:37 -0400, Scott Trudeau wrote:
Theoretically, a way to "sync" Drupal site instances (Google Gears aside) would be awesome. Practically, it is a very hard problem to solve since most Drupal sites are in constant flux "in the wild" and therefor, once you "copy" a local version of the site and make changes, you have two separate branches with many potential opportunities for collision. You can handle some sync collisions intelligently but there will always be weird cases. Also, I can't even begin to imagine how much more effort it would take to build modules that can handle a sync framework.
And then ? It's the same thing when you take your time to add or edit a node on a busy site: you've got a "temporarily offline" reference in your web browser which is "synced back" to the database when you press "save".
Right. But what happens when a user on the live site adds a new node at the same time I add a new node on the local copy and the node id conflicts? What happens if a user edits a node on the live site that I also edit on the local copy? And that's without getting in to more comples site configuration syncing issues ... Not impossible, but trickier than it might seem. And on this same thread, a quick proof-of-concept by a Wordpress developer for syncing Wordpress content offline using Google Gears: http://blog.assembleron.com/2007/05/31/google-gears-caching-of-wordpress-in-... Scott On 6/1/07, Xavier Bestel <xavier.bestel@free.fr> wrote:
On Fri, 2007-06-01 at 10:37 -0400, Scott Trudeau wrote:
Theoretically, a way to "sync" Drupal site instances (Google Gears aside) would be awesome. Practically, it is a very hard problem to solve since most Drupal sites are in constant flux "in the wild" and therefor, once you "copy" a local version of the site and make changes, you have two separate branches with many potential opportunities for collision. You can handle some sync collisions intelligently but there will always be weird cases. Also, I can't even begin to imagine how much more effort it would take to build modules that can handle a sync framework.
And then ? It's the same thing when you take your time to add or edit a node on a busy site: you've got a "temporarily offline" reference in your web browser which is "synced back" to the database when you press "save".
On 6/1/07, Scott Trudeau <strudeau@umich.edu> wrote:
Right. But what happens when a user on the live site adds a new node at the same time I add a new node on the local copy and the node id conflicts? What happens if a user edits a node on the live site that I also edit on the local copy? And that's without getting in to more comples site configuration syncing issues ...
Not impossible, but trickier than it might seem.
And on this same thread, a quick proof-of-concept by a Wordpress developer for syncing Wordpress content offline using Google Gears:
http://blog.assembleron.com/2007/05/31/google-gears-caching-of-wordpress-in-...
I attended Google Developer day and sat through most of the Google Data API, Mash-up sessions. They resolve conflicts using Optimistic Concurrency. Their API is completely REST so it's something we could also implement in Drupal. http://code.google.com/apis/gdata/reference.html#Optimistic-concurrency I assume that Gears makes use of this data API to resolve these issues. Cheers, Kieran Scott
On 6/1/07, Xavier Bestel <xavier.bestel@free.fr> wrote:
On Fri, 2007-06-01 at 10:37 -0400, Scott Trudeau wrote:
Theoretically, a way to "sync" Drupal site instances (Google Gears aside) would be awesome. Practically, it is a very hard problem to solve since most Drupal sites are in constant flux "in the wild" and therefor, once you "copy" a local version of the site and make changes, you have two separate branches with many potential opportunities for collision. You can handle some sync collisions intelligently but there will always be weird cases. Also, I can't even begin to imagine how much more effort it would take to build modules that can handle a sync framework.
And then ? It's the same thing when you take your time to add or edit a node on a busy site: you've got a "temporarily offline" reference in your web browser which is "synced back" to the database when you press "save".
-- To strive, to seek, to find, and not to yield.
participants (4)
-
Kieran Lal -
Michelle Cox -
Scott Trudeau -
Xavier Bestel