On Fri, Aug 01, 2014 at 02:08:38PM -0400, Jan Harkes wrote:
> On Fri, Aug 01, 2014 at 09:20:17AM -0400, Greg Troxel wrote:
> > Has anyone gotten coda to run on android?

> A custom client application that can talk to Coda servers and can be
> used to navigate the file system and fire off the right intents to
> launch appropriate applications to handle the various file is a better
> approach than actually trying to keep a (mostly) unmodified Coda client
> running.

A nice idea.

A corresponding utility for other platforms (similar to smbclient)
would be useful in general (of course best with both a CLI and as
"*fs"-modules to popular file managers...).

What this is akin to is to abstract Venus as a library, then
the android case becomes "almost straightforward".

Such a library would be certainly useful (and a samba binary linked to
it could be used as a Windows/MacOS local gateway to Coda).

On the other hand, android's limitations aside, the easiest and the
most flexible way of doing this is to make a slim shim library capable
of talking the upcall protocol to Venus.

IOW instead of linking in the Coda-related code and sharing the address
space with it (with all known related problems), just pass data back
and forth, the needed interface is already available.

handling accesses to both inside and outside of the /coda file tree
in an interception layer.

It looks like there are good prerequisites for creating such a simpler
library. May be this would qualify for a GSOC project?

Returning to android, I wonder how much of functionality such a client
needs to implement to be useful? A certain level of caching is probably
necessary - a single file? This would allow interoperability but
throw away some of Coda advantages. How much could be gained in the code
simplicity by implementing such a minimal venus replacement?

Just half-random thoughts triggered by Jan's suggestion.

Rune