Hi,
intrigeri <intrigeri@???> wrote:
> Alan wrote (22 Feb 2015 01:48:28 GMT) :
> > intrigeri <intrigeri@???> wrote:
> >> Alan wrote (20 Feb 2015 19:43:10 GMT) :
> >> > I'm not opposed to exposing a DBus interface in a future version of
> >> > TorMonitor to provide the "green onion" or other applications more
> >> > information that our hooks could. But I'm not sure it is the right
> >> > place to do it yet.
> >>
> >> What would be a better place to do it in your opinion?
> >>
> > In my opinion, the easiest method to replace vidalia's green onion
> > would be to write a very small GNOME Shell extension that would listen
> > to a very simple DBus service.
>
> Did I get it right that this extension will actually *provide* that
> DBus service? And then other stuff (see below) will connect to it to
> notify the extension that Tor is up?
>
It may indeed be the easiest to do, even it it sounds a bit reverse
logic.
> > The very same mechanism that currently
> > displays the "Tor is ready" notification in Tails would trigger a
> > notification to this DBus service that would update this onion. I admit
> > this would be very Tails specific.
>
> I think we can go this way (or similar) for the first iteration, that
> replaces what Vidalia gives us, including the buggy green onion.
> So I've created #9002, as a child ticket of #6841 ("Replace Vidalia").
>
> Now, in the first iteration, the information we want to convey to that
> Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
> is down" on network post-down).
Really? I though we wanted bootstrap progress too, that current
vidalia's onion provides (no onion/red > yellow > green)
> Using DBus to convey this information
> seems vastly overkill to me, to the point of being a little
> bit ridiculous.
>
If we only want a boolean status, I agree with you.
> If that saves us time for the next iterations, why not. But for the
> next iterations of that extension, the listening direction may change
> (I expect that something else will provide the DBus service that
> provides updates wrt. the status of Tor connectivity, and the Shell
> extension will connect to that service to get these updates), so
> perhaps it's really not useful to get DBus onboard before we have
> a clearer idea of the design for the next iterations.
>
> An alternative, for the initial iteration, is to do exactly what we're
> doing now: when we display "Tor is ready", simply enable the Shell
> extension that displays the green onion. And disable it when the
> network gets disconnected. This way, we don't even need any
> communication channel :)
>
This can be done by changing a GSetting. I do not find it very elegant
to change a setting at each network status change, but it may work. I
didn't found a DBus interface to enable/disable extensions. At first
glance, I think DBus might still be the more appropriate.
> > Please note that I'm not aware of such a concept of "connectivity
> > status" in Tor. If you know about it, don't hesitate to point me to
> > relevant documentation.
>
> No idea. Is it equivalent to having circuits open? I think Tor tries
> to maintain circuits open even when they're not requested by clients,
> so if there's no circuit open, perhaps Tor can be considered
> as disconnected?
>
Tor always tries to build circuits, so it has circuits in "launched"
state. We could consider Tor as "connected" as long as it has at least
one circuit in "built" state.
[...]
> > To sum up, I see three options (on order of complexity) to feed this
> > GNOME shell extension that would provide the onion:
>
> > 1. through the same mechanism that displays the "Tor is ready"
> > notification;
> > 2. through a DBus service that would be a separate process that the
> > Tor Monitor application (but managed in the same project);
> > 3. through a DBus service that would be tightly integrated in the Tor
> > Monitor application.
>
> I say let's go with (1) as far as #6841 is concerned.
>
I agree it's the easiest way to start with.
Cheers
