Re: ppp support

> I don't really understand the need of this project at all. NM already
>  contains a class for that, it even has the exact same name as your
>  project. Why not just improve that? That should take care of
>  collaboration and there won't be a need for merging.

I see it in the tree but I don't see it works, correct me if i'm wrong.

nm-ppp-manager works mainly on serial ppp links as I see.

We should think more abstractly on PPP. NMPPPManager class should
handle and track any kind of PPP not only modem links, all phy-link
specific stuff should moved away from it, it should just take care
about pppd. So all functionality should be implemented in subclasses:
which options to be supplied, are they correct, create serial
link(bluetooth, br2684) and so on.

I see the setting class. I think PPPObject should own them, how do you
like such kind of subclassing br2684->pppoe->pppd. br one shares
options with pppoe.

please take a look at my sources to understand what I mean, just want
to keep it simple,
some examples of how it works, small tool called 'tool' passes options
to the service:

python ./ type pppoe device eth1 user foo password bar
python ./ type gprs device rfcomm://xx:xx:xx:xx:xx:xx user
beeline password beeline gprs-context 1 gprs-packet-type ip gprs-apn
python type pptp  pptp-server  user no1sm
password XXXXXX route-replace ''

excuse me for my poor english.
say me that I'm wrong, I just wanna to see that kind of ... working
under GNU/Linux system,
so my friends can set it up them selfs, as easy as it possible.

ps: did you see maemo, it have nice profile manager for GPRS settings
was always dreaming about such thing, you just select kind of ppp,
physical device, isp and in some cases user/password pair, and here
you are on.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]