Misc. questions about startup, running when not logged in, and stable addressing.

[jwhitlark]

Hi all,

So I really like couchDB, and I really like the idea of desktopCouch,
I just have a couple of concerns about using it in my applications
where I'd like them to be able to also run on vanilla couchDB also.
Of course, it's possible I missed something and these use cases are
already handled in some way.

1) It seems like the only way to start it is as the locally logged in
user. I'd like to store data in there which would be usable even when
I wasn't logged in, for daemons, cron jobs, etc. I'd also like
replication to happen even though I wasn't logged in, as a lightweight
backup and to speed things up when I do log in. Would the design of
desktopCouch allow for this?

2) DBus isn't always the easiest to get to, especially in cases where
I was planning on doing all my work over http. What do you think
about a lightweight proxy, something that would forward
localhost:std_port/username/couchXYZ to localhost:port_from_dbus/
couchXYZ?

I'm fine with writing code myself, but I'd like to know the necessity,
feasibility, and where to start from someone who knows their way
around the codebase.

[Stuart Langridge]

On Mon, 2010-10-11 at 10:51 -0700, jwhitlark wrote:
> So I really like couchDB, and I really like the idea of desktopCouch,
> I just have a couple of concerns about using it in my applications
> where I'd like them to be able to also run on vanilla couchDB also.
> Of course, it's possible I missed something and these use cases are
> already handled in some way.
>
> 1) It seems like the only way to start it is as the locally logged in
> user. I'd like to store data in there which would be usable even when
> I wasn't logged in, for daemons, cron jobs, etc. I'd also like
> replication to happen even though I wasn't logged in, as a lightweight
> backup and to speed things up when I do log in. Would the design of
> desktopCouch allow for this?

Ah. No, it doesn't. DC isn't really designed to be a system-wide thing;
I understand the reasoning (it'd be good to get at your data stored in
desktopcouch from a cron job running as you), but the use-case for
desktopcouch is as part of your desktop. It deliberately uses things
like the keyring and D-Bus to take advantage of that. As such, it's not
really suitable for un-logged-in environments, I'm afraid.

> 2) DBus isn't always the easiest to get to, especially in cases where
> I was planning on doing all my work over http. What do you think
> about a lightweight proxy, something that would forward
> localhost:std_port/username/couchXYZ to localhost:port_from_dbus/
> couchXYZ?

That'd be somewhere in between hard and impossible, because the proxy
would have to be running as you to make a D-Bus call to your session bus
to get the port, which means that it could only proxy for your DC (and
not any other users).

Sorry, it sounds like I'm trying to, er, urinate on your bonfire here,
but I think the sorts of use-cases you're aiming for are not the sorts
of things that DC was designed for. It might be possible to contort
things such that DC does what you want, but it'd be really quite
hard :-(

sil

[Vincenzo Di Somma]

On Mon, 2010-10-11 at 20:34 +0100, Stuart Langridge wrote:
> On Mon, 2010-10-11 at 10:51 -0700, jwhitlark wrote:
> > So I really like couchDB, and I really like the idea of desktopCouch,
> > I just have a couple of concerns about using it in my applications
> > where I'd like them to be able to also run on vanilla couchDB also.
> > Of course, it's possible I missed something and these use cases are
> > already handled in some way.
> >
> > 1) It seems like the only way to start it is as the locally logged in
> > user. I'd like to store data in there which would be usable even when
> > I wasn't logged in, for daemons, cron jobs, etc. I'd also like
> > replication to happen even though I wasn't logged in, as a lightweight
> > backup and to speed things up when I do log in. Would the design of
> > desktopCouch allow for this?
>
> Ah. No, it doesn't. DC isn't really designed to be a system-wide thing;
> I understand the reasoning (it'd be good to get at your data stored in
> desktopcouch from a cron job running as you), but the use-case for
> desktopcouch is as part of your desktop. It deliberately uses things
> like the keyring and D-Bus to take advantage of that. As such, it's not
> really suitable for un-logged-in environments, I'm afraid.

I totally agree with Stuart but, maybe, you can find a way to replicate
your local desktopcouch couchdb database to a different server and from
there give access, but sooner or later you'll have to log in.

vds

[jwhitlark]

On Oct 11, 12:34 pm, Stuart Langridge <stuart.langri...@canonical.com>
wrote:

> On Mon, 2010-10-11 at 10:51 -0700, jwhitlark wrote:
> > So I really like couchDB, and I really like the idea of desktopCouch,
> > I just have a couple of concerns about using it in my applications
> > where I'd like them to be able to also run on vanilla couchDB also.
> > Of course, it's possible I missed something and these use cases are
> > already handled in some way.
>
> > 1) It seems like the only way to start it is as the locally logged in
> > user.  I'd like to store data in there which would be usable even when
> > I wasn't logged in, for daemons, cron jobs, etc.  I'd also like
> > replication to happen even though I wasn't logged in, as a lightweight
> > backup and to speed things up when I do log in.  Would the design of
> > desktopCouch allow for this?
>
> Ah. No, it doesn't. DC isn't really designed to be a system-wide thing;
> I understand the reasoning (it'd be good to get at your data stored in
> desktopcouch from a cron job running as you), but the use-case for
> desktopcouch is as part of your desktop. It deliberately uses things
> like the keyring and D-Bus to take advantage of that. As such, it's not
> really suitable for un-logged-in environments, I'm afraid.

I understand. I was thinking that the focus was more on personal db
and less on desktop db. My feeling was along the lines of "my
computer doesn't stop being mine when I'm not logged in, " but these
are different use cases; I was hoping it would be able to meet both,
but perhaps not. Am I correct in assuming that desktopCouch can
replicate with a standard couchDB via the usual methods?

Also, from you comments, I'm going to assume that desktopCouch shuts
down when you log out? (I'm not against ever logging in, I'm just
against having to be logged in for replication to take place.) Ah, I
suppose that is what UbuntuOne is for, to be the always on replication
point?

> > 2) DBus isn't always the easiest to get to, especially in cases where
> > I was planning on doing all my work over http.  What do you think
> > about a lightweight proxy, something that would forward
> > localhost:std_port/username/couchXYZ to localhost:port_from_dbus/
> > couchXYZ?
>
> That'd be somewhere in between hard and impossible, because the proxy
> would have to be running as you to make a D-Bus call to your session bus
> to get the port, which means that it could only proxy for your DC (and
> not any other users).
>

Hmmm, a two stage, two process proxy, one running as root, one under
your username? Still, there isn't a lot of point of pushing something
too far out of it's target environment. I'd rather have two separate
tools that do their job well, than a single tool that does nothing
well.

> Sorry, it sounds like I'm trying to, er, urinate on your bonfire here,
> but I think the sorts of use-cases you're aiming for are not the sorts
> of things that DC was designed for. It might be possible to contort
> things such that DC does what you want, but it'd be really quite
> hard :-(
>

No problem. I asked because I wasn't sure. Thanks for taking the
time to help me out.

> sil