Il giorno gio, 10/09/2009 alle 12.59 -0700, Dan Williams ha scritto: > On Mon, 2009-09-07 at 12:53 +0200, Pietro Battiston wrote: > > By looking at bugs filed and words spent in several different bug > > trackers and mailing lists, I fear NM developers may be quite allergic > > to the words forming the subject of this email, but though indeed the > > problem gathered a big attention, I didn't find any (reasonably recent) > > documented answer to the three questions I'm asking, so here ends the > > prologue: > > > > > > 1) the most clear answer I found to the claim: > > > > "NM doesn't support generic ppp, so I must connect with > > $APP_TO_HANDLE_PPP_CONNECTION and NM doesn't notice it, so > > $APP_USING_NETWORK doesn't connect, thinking I'm disconnected" > > > > is at [0] and basically says: > > > > "nobody is working on it, if somebody would like to, please step in". > > > > This was obviously an admissible position; is it still true, or did the > > creation of MobileManager change future hopes of generic (or at least > > bluetooth) ppp support in NM? I ask it because the name of the project > > seems to suggest it, though in presenting it at [1], Dan only talks > > about "All mobile broadbands", and the same does the README. > > > > > > 2) supposing that answer to 1) is "no, people connecting via a > > traditional modem or a mobile via bluetooth shouldn't just hope NM > > supporting them soon", then wouldn't it make sense to allow _setting_, > > instead than just _querying_, online/offline status via DBUS? > > > > This would allow, with few lines of code, tools like Gnome-PPP to say > > "hey, NM, we _are_ online"[2] > > > > Then, in the network connections menu, an item "externally managed > > connection" could also possibly show up and activate... > > > > I perfectly understand this is not something NM developers dream of, > > being not part of the standard infrastructure, but it would be of huge > > help to those who - like me and many people I know of (BTW, from > > personal experience I frankly doubt about the 98% Alexander's estimate > > in [0]) - need to connect via bluetooth/standard modems (it may be OT, > > but let me mention that this is one of the few things Windows/OS X > > softwares do nicely since many years and Linux Desktop doesn't). > > > > I (don't know NM internals and) suppose some things may not work as > > usually: for instance, I can imagine sharing a connection would be a > > problem, if NM doesn't control it... but _this_ is really a minor > > problem. > > Please read: > > http://mail.gnome.org/archives/networkmanager-list/2009-May/msg00004.html read, sorry for not noticing it before "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." You perfectly know the real benefit, because lots of people talked about it: Firefox, Pidgin and so on will know you're connected. "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." That's what I absolutely hope: that the hack will no more make sense in 6 months or a year. But let me calculate how many times I'll click "Online mode" in Firefox in 6-12 months and multiply by the number of users... Don't know exactly, but it's a lot. (and at least _I_ know what's the problem, so I won't loose time searching for the solution, like many less expert Linux users do) > > > 3) Why was PPP generic support dropped? Because it was broken/lacking > > manpower or just because mobile broadband support covered many of the > > use cases of it? > > Dropped precisely because it was a complete non-integrated hack which is > not what we want, as described by the above mail. The above mail was from a developer of another project which asked you to change the architectural view of NM, by interoperating with external components. I'm asking you a hack: a dbus call to say "please say to clients we're online". I _know_ VPN won't work and we'll have no information about the connection. _Those_ are minor issues. > > To repeat: NM tries to manage your network connectivity. And if it > doesn't have enough information to do that (because it's not managing > your default internet connection) then it's pretty hard to do a good job > of that, and you'll find that NM and whatever other method you're using > (gnomeppp or whatever) are stepping on each other's toes. Want to use > one of the NetworkManager VPN plugins with your externally-managed > connection? You can't, precisely because it's externally managed and > there's not *one* entity that has all the necessary information to make > intelligent decisions about the network. > > Ok, so what if we have whatever else is managing the connection push a > bunch of information to NM and send all sorts of signals around to keep > connection state updated? That's just about as much work as just adding > the support to NM, and we'd need to add stuff to NM to handle lifecycle > management of that external program anyway to clean up if it crashes, > etc. If gnomeppp dies unexpectedly, what's left around to tell NM that > you're longer online? > > These sorts of things are stuff that many people don't think about: the > *whole* picture, not just one partial use-case. > > The solution: fix NM so it's able to handle your device natively. It's > not that hard, it simply requires some time. It's on the list, but the > more people that have time to help out, the faster it gets done. > > Dan > > OK, OK, sorry, I have this very bad abitude of writing too much: my email should have been just: "May I ask you to allow me to change the state NM reports to clients via dbus?" _this_ is a hack indeed, but it's _very_ simple. And it's enough to solve the main problems of thousands of people until PPP works. I know nobody can oblige anybody to work on NM, so I perfectly know that, as in any ((free?) software?) project, the only limit is human time. That's why I can understand we have to wait for PPP, and try to survive in the best possible way. I don't have the time to write a PPP NM component (I don't even have the time to develop the skills, theoretically my exams wouldn't even let me time to write this email). I think I may find the time, if this is the problem, to produce a patch for the simple hack I'm talking about. That's the main reason I insist for applying it and I don't insist for enabling PPP in NM. So please don't answer to me "if you/somebody helped, PPP would be done sooner" (which was possibly the right answer for the developer of VMC). That said, really, the last thing I want is to waste your time answering to this email, so if you just give more value to NM being hack-free more than to PPP users being happy of it for the next 6-12 months, I simply have no way to convince you and I will stop bothering you from... now. Pietro Battiston
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente