Re: Bluetooth support

[Dan Williams <dcbw redhat com>]

On Mon, 2009-01-12 at 09:29 +0200, Antti Kaijanmäki wrote:
> On Thu, 2009-01-08 at 13:26 -0500, Dan Williams wrote:
> > > DUN on the other hand can not be made as a new device class as it's just
> > > a way to get a serial device for NMGsmDevice and NMCdmaDevice. It would
> > > be clear to separate NMSerialDevice to NMHalSerialDevice,
> > > NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
> > > like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
> > > NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice we
> > > can't do the split; that would lead to NMBluetoothGsmDevice,
> > > NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
> > > type enumeration.
> > > 
> > > Instead I suggest that we handle the different serial types inside
> > > NMSerialDevice. Let's add a 'type' option to serial configuration.
> > > NMSerialDevice would then handle these different types internally. The
> > > different types would be specified as an enumeration like {hal,
> > > bluetooth, path, irda, ...} The option would be optional and default to
> > > HAL.
> > 
> > Or, make the GSM and CDMA bits GInterfaces instead that any particular
> > device can implement...  That's the cleaner route actually.
> 
> Wouldn't we still end up with HalGsmDevice, BtGsmDevice, ..., which
> would implement either GSM or CDMA interfaces? The only difference
> between e.g. HalGsmDevice and BtGsmDevice is the way how serial device
> is discovered and initialized and all GSM funtionality would have to be
> duplicated.. 

No, because you would make the GSM and CDMA code a GInterface which the
straight serial or BT class would implement, but of course all the
common code can still live in the GInterfaces.  As you correctly point
out, the behavior is the same once you have a serial port, so I doubt
the BT class would need to override much of anything in the
NMGsmInterface or NMCdmaInterface code.  GInterfaces are slightly
different than Java, for example, in that the interface itself can also
have a bunch of code and the class that implements it only needs to
override that code if necessary.

> IMO the right place for abstraction would be NMSerialDevice; we could
> turn that to a GInterface. We can't derive NMGsmDevice and NMCdmaDevice
> directly from GInterface, but we could have the NMSerialDevice as a
> member of those both classes. Then on device creation time just specify
> which class implementing NMSerialDevice interface you actually want. Of
> course this would prevent us from casting e.g. NMGsmDevice directly to
> NMSerialDevice and thus break backward compatibility;
> instead of  NM_SERIAL_DEVICE (foo)->bar ();
> we would do NM_GSM_DEVICE (foo)->get_serial_device ()->bar(); 

NMSerialDevice may well be the best place to put the abstraction, but I
don't think it needs to be done as you've described it.  Most of
NMSerialDevice will go away pretty soon and be replaced with
ModemManager, thus there will be a *lot* less code there that needs to
be shared.  All that's left is PPP handling.  We may well be able to get
away with killing NMSerialDevice as a class in the first place, and
putting its functionality into a small helper file instead.

Then we're left with NMBluetoothDevice, from which is derived
NMBTGsmDevice and NMBTCdmaDevice, and the old NMGsmDevice and
NMCdmaDevice which all just talk to ModemManager for the device setup,
and share the common PPP handler code.

Dan