2009/5/1 Dan Williams <[email protected]>
> On Thu, 2009-04-30 at 20:23 +0100, Andrew Bird (Sphere Systems) wrote:
> > Hi Pablo,
> > Speaking as a developer of VMC, I find NM's position of being the
> well known
> > place for applications to find out if they have network connectivity
> logical,
> > but also frustrating. Not providing an interface for 3rd party connection
> > managers to publish their status means we have to ship our product in a
> > condition that almost all users will find bewildering. Currently we can
> > successfully make a connection to a mobile network, the user then opens
> > Firefox and he is told that it's offline; now that's not user friendly.
> Of
> > course there are workarounds for Firefox, but there are other apps that
> do a
> > similar thing, surely we don't have to go and modify them all. Doing that
> > would throw away all the benefit of NM being the well known interface it
> is.
> > In the future I'd like a dbus interface fitting to NM that allows
> 3rd party
> > apps to publish their online status. Nothing too fancy is required, just
> a
> > possibility to get ourselves out of the hole we find ourselves in.
>
> "Nothing fancy" is the problem here, because it's not just about
> online/offline. It's about providing applications an interface to
> determine information about network connections and network state, which
> a simple "am I online" doesn't do. What you want is really some sort of
> 3G connection manager plugin interface to NetworkManager, where you
> could plug in your own 3G connection manager. That would require (a) a
> stable plugin API which has both benefits and drawbacks, (b) the plugin
> to use the existing NetworkManager configuration mechanism for all its
> configuration, and (c) provide NetworkManager the IP configuration and
> DNS addresses such that NM could then set up the network interface after
> the connection.
This would be by far the easiest method, as it would require fewer changes
than other approaches, however there are platforms, like Moblin, where
NetworkManager will never run, thus this approach won't work.
>
>
> That's what ModemManager is already. I'm not quite sure why everyone
> doesn't coalesce around *one* 3G modem management service, because
> there's enough odd hardware out there that centralizing all the
> knowledge in one place has huge benefits. It's better for users. The
> problem is that we need that service to be in a lower-level language
> than Python, because not all platforms have the resources, ability, or
> desire run the whole python stack, both due to code size and memory
> size.
>
> I used to work on OLPC, which uses Python intensively. And we didn't
> choose Python for its memory usage, and that came back to bite us later.
> Java is a ton better than Python there because you can share the
> majority of the pages in Java processes with each other; because they
> all run on the same VM. But with Python, you can really only run one
> Python process per VM, and you loose all the sharing ability. Thus
> you're left with Python being a memory black hole. But Java has a much
> larger on-disk footprint. But I digress...
>
> If people think it's a good idea to have *one* low-level modem manager
> service with a D-Bus interface that any higher-level connection manager
> could use (be it NM or ConnMan or Wader GUI), then lets do that. Since
> it's D-Bus, it doesn't matter whether it's ModemManager or whether you
> guys all want to write your own ModemManager implementation in Python.
> Whatever.
Sure, that's why Wader embraced the ModemManager API. It is not that we like
to reimplement stuff on Python, lets not forget that both VMC and Wader
codebases are older than ModemManager's. (VMC started in late 2006).
>
> But the core problem is that network management is a *system-wide*
> problem, and you can't just write one component and call it a day. The
> policy needs to make informed choices based on the entire network state
> of the machine. And the configuration of all the network connections
> needs to be in *one* place, with *one* format, not spread around in 3
> different locations because you're trying to put 2 or 3 connection
> managers on the same machine. There should only be one connection
> manager running at any given time, or else you've just (a) doubled your
> work and QA, and (b) made it suck for users because configuration is
> split up, and (c) behavior is different than they expect.
This is how you register for network notifications on OSX:
notify_register_file_descriptor("com.apple.system.config.network_change",
&fd, 0, &netNotifyToken)
Ideally, on Linux, it should be something similar. A well known interface
that is not coupled to a particular connection manager. Every connection
manager would be a "connection provider" that would register with that
particular iface. Connectivity queries would then perform a logical OR with
all the replies of the registered providers. i.e: NetworkManager.Connected
== 0, Wader.Connected == 0, ConnMan.Connected == 1. Then the reply would be
connected, as `0 | 0 | 1` == 1.
This is just a quick idea, I guess that perhaps freedesktop.org people
should come up with the exact interface as this is affects all Linux users.
Regarding doubling the ammount of QA and unhappy users, let's not forget
that your vision is the NetworkManager vision. You guys are very happy with
the current situation, but is unfair for similar projects. Imagine that it
was the other way around, and you and your users are very frustrated because
despite the fact that you're connected, all your apps believe is the other
way around and nothing works.
>
>
> Fundamentally, NetworkManager + ModemManager and Wader + VMC are trying
> to do the exact same thing. Control 3G connections. Why do we have
> more than one program that controls 3G connections? Carrier branding
> and control? Territorial issues? Existing project momentum and
> userbase? What are everyones requirements, and why can't we find one
> project that we can make handle all those requirements in a systematic
> manner?
Why do we have Firefox and Epiphany on Gnome? Why pidgin/gajim/empathy? Why
rhythmbox and banshee?
It is what makes great Linux, the variety and choices that users have.
Some of the goals that we have for Wader, do not fit into NetworkManager.
Will you support USSD? Will you support Contacts/SMS?
Then you have OEMs, that like to add some branding to apps you know?
>
>
> Seems to me it would be easier to make ModemManager work better for your
> use-cases than to add Ethernet + WiFi to Wader/VMC. I'm quite open to
> whatever suggestions people have for NetworkManager and the applet.
> There simply hasn't been enough manpower to do everything that we've
> wanted to do with NM, which is why there are things people want out of
> NM that aren't yet supported. If there are issues with NM's
> configuration format or interface, I'm quite happy to figure out how to
> fix that. If there are issues with NM's handling of devices and
> routing, I'm also happy to figure out how to fix that.
>
> But at the end of the day, focus must be on the users. Within the NM
> framework (ie, letting NM control your primary network connection) we
> think that works pretty well. But it's hard to see how an interface to
> NM to let other apps say "hey, I'm online now" without providing the
> other benefits of unified configuration store and UI, unified D-Bus
> interface for applications to determine network configuration and setup,
> and a single UI for controlling all your network connections, would be a
> real benefit to users.
Every application should be able to query the network status, in most
distros with the -server flavor, NetworkManager is not installed at all.
What would be your solution for this use case? And yes, DBus *is* used
nowadays in server configurations, see [0]. That's why I mentioned that
perhaps freedesktop.org people should be involved in this discussion.
>
> Say an application only wants to bring up email or IRC when you're
> connected to VPN. That requires knowledge of configuration of the L2
> device (which could be wifi, wired, 3G, bluetooth, a bridge, a bond,
> etc) *and* the VPN connection.
>
> Or your software updater, which you may not want to run when on metered
> connections like 3G or WiMAX or even Cable+PPPoE. Now it can just ask
> NetworkManager whether it's on an expensive connection. But were
> something else (Wader or VMC or ConnMan) handling the 3G connection
> *only*, now the software updater has to ask *all* connection managers
> (NM, Wader, ConnMan, etc) what type the connections are. That's now 3x
> or 4x more code than just talking to NM. And 3x to 4x more QA work.
Its not that applications need to listen for every possible signal that
Wader/VMC/ConnMan/NM emits, we need a central point for connecitivity
status.
This is an excellent choice to come up with a powerful API that applications
can start to use. Your idea about L2 is very good, and that would put us
ahead of, at least OSX, whose update manager does not take into account if
you're connected via 3G.
>
>
> So, you might say, lets extend the abstracted online/offline service to
> contain connection type too. And then maybe connection "cost" and IP
> address too, since some programs might want to use D-Bus for that
> instead of SIOCGIFCONF. Isn't this just recreating NetworkManager with
> a more limited API? And apps would still have to talk individually to
> each connection manager for anything more sophisticated.
>
> There's a lot more to the problem than online/offline. Just talking
> about online/offline is hacking around the immediate problem without
> making the system as a whole better for the users. It fixes your
> immediate problem, but it doesn't actually make things better in 6
> months or a year.
Sure, thats why we need to engage on a discussion about all this and come up
with a powerful and beefy API that sets the pace.
[0] http://trac.ebox-platform.com/search?q=dbus
Best regards,
Pablo
>
>
> Dan
>
>
> >
> > Best regards,
> >
> >
> > Andrew
> >
> >
> >
> >
> > On Thursday 30 April 2009, Pablo Martí Gamboa wrote:
> > > 2009/4/30 Dan Williams <[email protected]>
> > >
> > > > On Thu, 2009-04-30 at 14:06 +0100, Marc Herbert wrote:
> > > > > David Sundqvist a écrit :
> > > > > > If I set it to be managed by NM, will NM try to manage it in any
> way?
> > > > > > Can I set it to be seen, but still unmanaged? Or maybe I could
> get NM
> > > > > > to always output a connected status instead of a no-connection
> which
> > > > > > triggers firefox offline mode, etc. (should the connection be
> lost,
> > > > > > well, then NM won't be able to detect it anyway due to being
> frozen
> > > > > > on the first page touch).
> > > > >
> > > > > There seems to be something fundamentally wrong in this
> no-connection/
> > > > > /offline thing. Since NM can be configured to manage _not all_
> > > > > interfaces (including none at all) then why are some applications
> > > > > wrongly assuming NM is always managing the entire network
> > > > > configuration? This seems to be where the bug lies and should be
> > > > > fixed.
> > > >
> > > > Its mostly a distro problem; if NM is not managing your default
> internet
> > > > connection, then you should probably turn NM off when setting up the
> > > > machine.
> > >
> > > Unfortunately, in today's Linux Desktop this will yield some main
> > > application unusable, they all rely on the NetworkManager interface for
> > > connectivity status. For projects that provide connectivity (ConnMan,
> > > Wader, VMC, K-MobileTools, gnome-ppp, etc.) is a frustrating situation.
> > >
> > > Even thou NetworkManager is the de-facto standard tool for managing
> > > connectivity, NetworkManager won't always be the solution for everyone.
> Say
> > > you have a token ring connection, NetworkManager doesn't have plans to
> > > support it. Say you provide dial up capabilities, like VMC, Wader, etc.
> It
> > > ain't gonna be nice, users have connectivity but applications are not
> > > aware. There are workarounds for applications like Firefox, but it is
> not
> > > something that a noob user will understand or do. For other apps like
> > > pidgin, there's no workaround AFAIK. Perhaps Moblin has patched
> Firefox,
> > > pidgin, etc. to listen for ConnMan's signals, but this is only possible
> on
> > > the OEM/distro level - i.e. I'm not gonna ship a patched
> firefox/pidgin/foo
> > > that listens for Wader's signals in my ppa/buildservice, it ain't gonna
> > > scale.
> > >
> > > It is gonna be a though process, but we need to engage all the
> interested
> > > parties on a discussion about how to make applications aware of
> > > connectivity changes and come up with a DBus interface that several
> > > applications can provide.
> > >
> > > I have already expressed this concerns to Dan Williams, and I think
> that
> > > @asac thinks something similar.
> > >
> > > What do you guys think?
> > >
> > > > The only way you can make intelligent decisions about the network
> state
> > > > on the machine is to make those decisions with *all* the necessary
> > > > information, and that means letting NetworkManager control all your
> > > > network connections.
> > > >
> > > > There are situations in which NM is not appropriate at this time, and
> > > > those are mostly situations where the primary network connection
> cannot
> > > > be controlled by NM for some reason. Thankfully, there are not too
> many
> > > > of those. Network-mounted-/usr is one of those cases, as are cases
> > > > where the root device is network-mounted, or where the interface
> cannot
> > > > be touched after exiting the initrd. For now, I'd suggest using the
> > > > static config scripts.
> > > >
> > > > A bullet-point on my feature list is to handle this case specifically
> > > > for wired non-802.1x connections, because all other types require too
> > > > much state to just be taken over post-initrd.
> > > >
> > > > Dan
> > > >
> > > > _______________________________________________
> > > > NetworkManager-list mailing list
> > > > [email protected]
> > > > http://mail.gnome.org/mailman/listinfo/networkmanager-list
> >
> >
>
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
_______________________________________________
NetworkManager-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
