Hi,
Alan wrote (20 Feb 2015 19:43:10 GMT) :
> On Thu, 19 Feb 2015 14:23:03 +0000
> sajolida <sajolida@???> wrote:
>> intrigeri:
>> > sajolida wrote (18 Feb 2015 11:32:17 GMT) :
>> >> intrigeri:
> [About the green onion]
>> >> but would it be conceivable to have Tor Monitor
>> >> appear as green onion on the desktop as Vidalia does until now?
>> >
> I don't think it's the way to go:
> - I'd like Tor Monitor to stay a generic application, with a clear
> focus on being a monitor for Tor and showing whatever icon on the
> desktop doesn't look like the same task for me.
IMO the "providing feedback regarding Tor connectivity status" feature
fits pretty well into the "monitoring Tor" mission. Perhaps we don't
put the same meaning behind "monitoring Tor".
Now, I do appreciate that you have a strong vision for what Tor
Monitor should be, and this is very useful to avoid feature-bloating
it :)
> - System Tray Icons were deprecated in Gtk since 3.14. A proper
> implementation of this "green onion" for GNOME 3 desktop would be a
> (very simple) Shell extension, to which "we" (the NetworkManager
> hook) should send a DBus signal (or the opposite). That might be a
> tiny funny project.
Ah, right. And glad you find it potentially funny :)
IMO, that Shell extension could very well be shipped in the same
upstream project as Tor Monitor, at least to start with: it would
benefit GNOME Shell users who would only have to install one single
package to get everything they need. And it wouldn't prevent the DBus
interface from being well-documented, stable, and re-usable by other
kinds of user feedback providers, be them desktop indicators
or whatever.
> 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?
(/me enters Alan's-mind-reading mode, let's try to guess what your
answer could be :)
I can imagine that we have a totally separate backend that monitors
Tor's connectivity status and sends DBus signals that e.g. a GNOME
Shell extension can receive and then provide feedback to the user.
I can see why there is no technical reason to couple this specific
feature with the rest of Tor Monitor's codebase. However, splitting it
out has a few clear disadvantages:
1. That's one more (presumably Python) process to run, which eats
memory etc. Of course, if we go this way, then we don't have to
run Tor Monitor by default, so it's only one *more* process for
users who manually start Tor Monitor, but still.
2. I suspect that this program will be doing very similar things to
Tor Monitor under the hood, and then we may quickly have more code
duplication than reasonable.
3. For anyone who runs both Tor Monitor and that backend process,
we'll be putting additional load on the Tor control port. No idea
if/how it's measurable in practice, perhaps Stem's polling loop is
so efficient that it's not.
4. That's one more upstream project to manage, release, tag, package,
import, etc. => not sure the overhead is worth it.
Granted, none of these arguments is very strong, except perhaps the
last one. If that backend program + Shell extension were shipped in
the same upstream project as Tor Monitor, then #2 and #4 are done
with, and I'm happy. Maybe we can reach a consensus on this design?
Cheers,
--
intrigeri
