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

Jeff Andros whitedrought at gmail.com
Thu Nov 30 03:44:33 CET 2006


On 11/29/06, Tim Newsom <cephdon at gmail.com> wrote:
>
> 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.


ah,  but XML has a lot of good tools to offload  the pretty portions onto
other servers... and we can pull a Google and use one-letter tag names to
cut down on space.  to see what I mean check out here:
www.asu.edu/clubs/paddle <http://www.asu.edu/clubs/paddle> all the stuff
that makes the site pretty is in the xsl-t page... I'm pretty sure we can
cut down on the bloat by setting up our schema for minimum size

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"

 Now that you mention it, I'm not really that sure either... but I think
you're right.
<snip>

> --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.  ;-)


amen, brother, amen

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
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
>
>
>


-- 
--Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20061129/3f6a696d/attachment.htm 


More information about the community mailing list