With read only geo tiles, security doesn't seem like it would be much of an issue.
The "standard" way to structure an app like that in Android seems like it would be to wrap up Couchbase Lite as a ContentProvider. @mjq -- didn't you guys do something like that? Do you have any pointers there? OTOH it seems like wrapping it up in a ContentProvider would be a fairly large undertaking, so let's ignore that for the time being and just consider the existing components. You'd probably want something like: - A separate app, call it TileServer, which would launch on device boot. - TileServer would start a listener (so it would need to include the java-listener <https://github.com/couchbase/couchbase-lite-java-listener> module) and expose the REST API <http://developer.couchbase.com/mobile/develop/references/couchbase-lite/rest-api/index.html>. The LiteServ <https://github.com/couchbase/couchbase-lite-android-liteserv> project is a good starting point, since it includes the java-listener module) - The listener would have no username and password basic auth, and so any other apps could connect to it on a known port. - If other apps needed to query javascript views, then the app would also need to include the javascript <https://github.com/couchbase/couchbase-lite-java-javascript> module. (and again LiteServ is a good starting point) On Wed, Jun 4, 2014 at 6:29 AM, Volker Mische <[email protected]> wrote: > On 06/03/2014 06:51 PM, Jens Alfke wrote: > >> >> On Jun 2, 2014, at 2:08 PM, Volker Mische <[email protected] >> <mailto:[email protected]>> wrote: >> >> I just got a question whether it is possible on Android to have a >>> central Couchbase Lite instance that holds the data and then >>> independent apps that access it. For example with using the Android >>> LiteServ (having access through HTTP would be good enough). >>> >> >> What's the advantage of doing it this way, as opposed to each app using >> its own embedded CBL? (That's not a rhetorical question; I know there >> can be advantages for certain use cases. For example, to share a very >> large database without duplication, or to let apps operate on shared >> data.) >> > > The idea is to have a central data provider where each user can download > his specific data. It may be worth several GBs (though I don't know if > that's really feasible with CBL). Then third parties should be able to > build apps on top of it. > > > CBL isn't intended to be a server and I'm a little bit wary of it being >> used as one, mostly for security reasons. I don't know if the listener >> implementation on Android supports passwords, for example. And it needs >> to be careful to avoid binding to network interfaces other than loopback >> (127.0.0.1) or it'll be reachable from other devices on the network, >> which greatly increases the attack surface. >> > > I'm also concerned about the security, but I would expect the central CBL > that holds the data to be more of a read only thing. It will sync to get > updates, but I don't expect the apps to change anything of it. > > Cheers, > Volker > > > -- > You received this message because you are subscribed to the Google Groups > "Couchbase Mobile" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/mobile-couchbase/538F1F41.2020304%40gmail.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/CACSSHCE2zRq-QKTE%3DXQy3z%2B_OWNChNJoooVLYCjb25Kc8_nmNw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
