network connections

[Sean Middleditch]

On Thu, 2003-10-02 at 15:59, David Zeuthen wrote:

> That is true. For most users, however, network connection == network
> device; but see below..

I'd highly disagree.  The only users this counts for are users of
desktop machines with only an ethernet port.  This is true for perhaps
cooperate networks, or people on home networks with a resident geek, but
not the average home user on dialup, the average laptop users, etc.

> 
> > HAL would certainly be useful for things like PCMCIA/cardbus network
> > adapters, and perhaps cat5 cable plugin/removal.  They are complementary
> > technologies.  ^,^
> > 
> 
> At some point HAL will support legacy devices like serial devices, e.g.
> modems. So, the obvious information to merge (from a device info file)
> for a modem would be
> 
>   Vendor = SomeVendor
>   Product = SomeProduct V.92
>   Bus = serial           # could be usb or pci as well
>   Category := Network
>   SubCategory := Modem
>   RequireEnable = true   # will have to explicitly enable the device
>   KernelDevice = /dev/ttyS0
>   BootProgram = some_dialing_script     # can inspect $HAL_<property>
>   ShutdownProgram = some_hangup_script
>   Network.Modem.InitString = ATZsomething
>   Network.Media = PPP
>   ConfigureRequiredProperties = Network.PPP.AuthLogin,
>                                 Network.PPP.AuthSecret,
>                                 Network.PPP.AuthType,
>                                 Network.PPP.Modem.PhoneNumber
> 
> (of course this needs to be specified in the hal spec before we
> implement it)

See, this I would recommend against.  This shoots the possibility of
profiles in the foot.  You certainly *can* do this in HAL, and it *may*
be good enough for most users, but since we need a profile system
*anyway*, one might as well just get all the pieces designed properly
once, vs. having HAL handle it all in some cases, netprofiles handling
it in other cases, etc.

> 
> So, when the device is discovered, it is not automatically enabled.
> Using libhal it can be enabled by some application but the application
> would need to set the required properties or the boot program would
> fail.
> 
> (actually one of the Arklinux developers I talked to on IRC are working
> on a libserial library (currently it can probe mice devices) so modem
> support may actually happen soon.)
> 
> I agree that network connections should be treated differently (windows
> also does this[1]) from devices, but I think the part where you interact
> with the actual network device could be handled by HAL with benefits. 

In the case of hardware devices, yes.  For the modem configuration, I'd
agree HAL should be used.  For things like username/phonenumber, which
are profile settings, I don't think HAL should be involved.  Not unless
you plan on duplicating all the profile work in netprofiles in HAL as
well, which seems a bit wasteful. ;-)

> 
> One could probably tweak HAL to do what you want, but I'm guessing
> usability guys would probably complain about that. Right?

I'd say a clean separation would work fine.  HAL would handle the
lower-level bits of the system; modem control strings, for one example. 
The netprofile backends (like, say, ppp) could then use HAL to find and
control the device.

It would also make sense to have netprofiles recognize devices using
HAL, versus the 'interface' parameter I put in my last mail - interface
should probably be handled by HAL.

I'd definitely say tho that all configuration of user-parameters (login
info, etc.) as well as connection control should be in netprofiles; we
need that kind of configuration whether we're using a plain hardware
device (ethernet card), or a wholly software based device (like cipe).

If you feel up to hashing over the jobs of each component in a network
situation, I'm quite willing to go over it; sooner this is worked out,
the closer we'll be to being able to pull up a real netprofile spec. 
^,^

> 
> Finally, I would be very happy to one day to be able to configure my
> (wireless) OpenVPN connection between my laptop and firewall, and I
> can't see that happening with only HAL and the direction I think it
> should go in. Today it's such a pain with OpenVPN (although OpenVPN is
> ubercool)...
> 
> Cheers,
> David
> 
> [1] : it's implemented in different ways.. The OpenVPN stuff is a
>       network device, while e.g. SecuRemote is not.
> 
> 
> _______________________________________________
> Xdg-list mailing list
> Xdg-list at freedesktop.org
> https://www.redhat.com/mailman/listinfo/xdg-list
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.