On 11/29/06, Tim Newsom <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> [email protected]
> http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
>
>
>
--
-- Tim
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
--
--Jeff
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
