Please think about incrementel sync Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone

[Tim Newsom]

Web services are XML data transfer.  The problem with xml is that it is
wordy for data (size) but good for parsing.  What I mean by that is that its
not the most efficient way to transfer data ( ok thats obvious) but its a
defined format and easy to parse just about anywhere.. just slow.

If you are keeping a copy of the current versions locally then diffing and
sending only the diffs would be easy... but to my knowledge svn only keeps
the diffs between versions at the repository. Someone who knowns please
correct me.  If I understand what you are saying and based on my
knowledge...
You either keep an old version for diffing purposes and replace it with the
current version when you do the commit.  All changes happen to the original
not the "old copy"

OR

You would have to have the repository local and commit the changes locally
but that doesn't help with the storage part.  The only way to sync up would
be through the dock.

My understanding of svn is that it transmits the entire file and the svn
server does the diff and only stores the differences between the files at
the repository.  I could be wrong about that though.

If you don't keep a repository locally then one way or another you will have
to obtain a copy of the old version in order to just sync changes somehow..

Its an interesting thought.. does anyone know for sure if SVN sends back
only the changes and how it does that if it doesn't fetch the previous
version for comparison?

--Tim

btw.. I tend to over explain things so if I don't go far enough please ask
me (I am trying to cut back)  ;-)
Also, feel free to correct me if I state something wrong.. I like to be
correct in my understanding and if I don't have all the necessary
information I would like to know what I am missing out on.  ;-)



On 11/29/06, Jeff Andros <whitedrought at gmail.com> wrote:
>
>
> <snip>
> >
> >
> > Without thougths like that you will have an incredible GPRS traffic =
> > costs.
> >
> > > ICS is really simple so
> > > we could host that from the device as well. If Apache isn't small
> > enough,
> > > even stripped down, there are several server apps that are optimised
> > for
> > > this kind of environment
>
>
> I don't do a lot of data on my phone at the moment mostly I use bluetooth
> for this kind of thing, so I hadn't thought about costs... the other thing
> we could try is an XML transfer of just the data, offloading the formatting
> onto another server... the cool thing about this is we could run both
> directly from the phone or from an intermediary depending on preferences and
> the particular situation.
>
> When you use an intermediary server, that will handle the heavy lifting on
> building the page and you could have a nice ajax-y interface, direct from
> the phone you could remotely store an XSL-T stylesheet to give you the
> frontend.  this minimizes the data that needs to go back and forth.  sending
> files back and forth I'd rather use something else, but in a pinch we could
> use an svn client which does send only the file diffs back and forth, plus
> storing the whole machine's drive on subversion gives us a nice backup in
> case someone throws you into the pool with your phone in your pocket (it's
> all fun and games until someone loses thier {email | phonebook | files |
> blackmail photos of drunk friends})  you could also use this like so:
>
> {user to phone} request update/commit cycle from phone to repository
> {user on desktop} update local copy of phone filesystem
> {user on desktop} make appropriate changes to files
> {user on desktop} commit to repository
> {user to phone} request update from repository
>
> where you are not on your phone, and are making commands from a browser
>
>
> Apache/whichever servers we're running handles the encryption, and now you
> can get to the current version of your system through websvn from anywhere
>
> --Jeff
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
>
>
>


-- 
-- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20061129/137d445e/attachment.htm