Android: Multiple apps using the same Couchbase Lite instance

268 views
Skip to first unread message

Volker Mische

unread,
Jun 2, 2014, 5:09:26 PM6/2/14
to mobile-c...@googlegroups.com
Hi all,

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

Before this thread turns into a "don't to that" thread, I'll explain
where the need comes from. It's mostly about storing image tiles to use
them as a base map for apps. It's really a specific case, it won't be
about generic apps, but about special purpose apps that just work with
this specific dataset (though the dataset can be different between users).

Cheers,
Volker

Jens Alfke

unread,
Jun 3, 2014, 12:51:51 PM6/3/14
to mobile-c...@googlegroups.com

On Jun 2, 2014, at 2:08 PM, Volker Mische <volker...@gmail.com> 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.)

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.

—Jens

Yaron Goland

unread,
Jun 3, 2014, 1:11:25 PM6/3/14
to mobile-c...@googlegroups.com

For whatever it's worth the Thali project (https://thali.codeplex.com) is using CBL for Java as a server and we do open it up on the net. But we had to put in our own security infrastructure (including mutual SSL auth and an ACL validation mechanism) and we certainly don't think it's ready for public use. In particular the HTTP stack it uses, TJWS, really makes me nervous. It's an ancient code base that is built with a custom tool and doesn't seem to get all that much love. My guess is that at some point we'll have to swap TJWS out with something a bit more robust like the Apache Listener.


My hope is to eventually get these changes put into the mainline couchbase rather than our custom forks.


        Yaron



From: mobile-c...@googlegroups.com <mobile-c...@googlegroups.com> on behalf of Jens Alfke <je...@couchbase.com>
Sent: Tuesday, June 03, 2014 9:51 AM
To: mobile-c...@googlegroups.com
Subject: Re: Android: Multiple apps using the same Couchbase Lite instance
 
--
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 mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/4D86C420-47F7-4AD5-9F03-D681249E67C5%40couchbase.com.
For more options, visit https://groups.google.com/d/optout.

Volker Mische

unread,
Jun 4, 2014, 9:30:51 AM6/4/14
to mobile-c...@googlegroups.com
On 06/03/2014 06:51 PM, Jens Alfke wrote:
>
> On Jun 2, 2014, at 2:08 PM, Volker Mische <volker...@gmail.com
> <mailto:volker...@gmail.com>> 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

Traun Leyden

unread,
Jun 4, 2014, 11:03:19 AM6/4/14
to mobile-c...@googlegroups.com

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 module) and expose the REST API.  The 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 module.  (and again LiteServ is a good starting point)




On Wed, Jun 4, 2014 at 6:29 AM, Volker Mische <volker...@gmail.com> wrote:
On 06/03/2014 06:51 PM, Jens Alfke wrote:

On Jun 2, 2014, at 2:08 PM, Volker Mische <volker...@gmail.com
--
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 mobile-couchbase+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/538F1F41.2020304%40gmail.com.

Matt Quinn

unread,
Jun 4, 2014, 1:56:57 PM6/4/14
to mobile-c...@googlegroups.com
On Wed, Jun 04, 2014 at 08:03:16AM -0700, Traun Leyden wrote:
> 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?

We haven't (although I've previously talked about experimenting with a
CBL SyncAdapter on this list).

I agree with you that a ContentProvider is probably the most "Android"
way to do this, and also that it would probably be a fair amount of
work. There's a pretty big SQLite assumption running through the content
provider stuff so you wouldn't get much help from the framework. I
imagine translating the SQL-style WHERE-clauses you'll get into view
queries would be the worst bit, but if you have a well-defined document
schema you should be able to translate the view results into e.g.
MatrixCursors without too much difficulty.

Can CBL-Android enforce read-only access through the HTTP API? Even if
the data isn't sensitive, I imagine you wouldn't want one of the
consumer apps changing it out from under everyone. That's another place
a ContentProvider would come in handy: implement just the 'query'
methods and the data should be isolated. Exposing data as a content
provider should also make it easier to consume by 3rd parties, since
they wouldn't have to add a CouchDB client to get at it.

Seems to me like a pretty big effort tradeoff though!

Matt

Volker Mische

unread,
Jun 5, 2014, 4:07:13 AM6/5/14
to mobile-c...@googlegroups.com
Thanks Traun, that's a great starting point.
Also thanks Matt for the follow up mail.

Cheers,
Volker

On 06/04/2014 05:03 PM, Traun Leyden wrote:
>
> 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
> thejava-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 <volker...@gmail.com
> <mailto:volker...@gmail.com>> wrote:
>
> On 06/03/2014 06:51 PM, Jens Alfke wrote:
>
>
> On Jun 2, 2014, at 2:08 PM, Volker Mische
> <volker...@gmail.com <mailto:volker...@gmail.com>
> <mailto:volker.mische@gmail.__com
> send an email to mobile-couchbase+unsubscribe@__googlegroups.com
> <mailto:mobile-couchbase%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/__msgid/mobile-couchbase/__538F1F41.2020304%40gmail.com
> <https://groups.google.com/d/msgid/mobile-couchbase/538F1F41.2020304%40gmail.com>.
>
> For more options, visit https://groups.google.com/d/__optout
> <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 mobile-couchba...@googlegroups.com
> <mailto:mobile-couchba...@googlegroups.com>.
> 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
> <https://groups.google.com/d/msgid/mobile-couchbase/CACSSHCE2zRq-QKTE%3DXQy3z%2B_OWNChNJoooVLYCjb25Kc8_nmNw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages