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..
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();
-- Antti
Attachment:
signature.asc
Description: This is a digitally signed message part