Scope and Using devices

[Owen Fraser-Green]

Hi,

> Now, should we include stuff like this is the IPv4 address of the
> networking device? Maybe, I'm not really sure, I tend to say no. Why?
> Because if we do this, should we do the same for IPX (isn't this a
> Novell protocol, btw?)? Or IPv6? 

I think the deciding factor here concerns the boundary between hardware
and software. Seeing as the IP stack isn't a part of the hardware
ethernet device, both getting and setting it's properties should just go
altogether (or alternatively, rename HAL to HOSAL: Hardware and Other
Stuff Abstraction Layer :)

> So, I still think we should stick with having things in libraries, and
> I'm not really sure it's sane to rely on a set-property API at all
> cf. my earlier comments regarding security and multiple things to
> change at the same time. Further, it would really tie us down insofar
> that the properties we would export would need to map one to one
> to ioctl stuff. Second, it would be rather difficult for application
> programmers to figure out whether a property can be set or not. 
> 
> Okay, so Owen raises a good point about us offering more interfaces,
> yeah, well we would, but probably not a lot. Also, in a hopefully
> not-so-far future people would use real object oriented languages so
> they could do stuff like
> 
>  if (obj.isinstanceof(Net.Ethernet.80211)) {
>      /* do stuff like set the ESSID */
>      try {
>          obj.set_80211_configuration(..);
>      } catch (SomeHalException exp) {
>          /* handle error */
>      }
>  }
> 
> or something..

Actually, you'd be able to do this today using hal-sharp if you did add
that interface:

if (device.GetType() == typeof(Net.Ethernet.80211)) {
   device.Set80211Configuration(..);
}

the problem is though that every time an interface changed or a new one
was added, I'd have to release a new version of hal-sharp since, for
this convenient syntax to work in .NET, the Net.Ethernet.80211 has to be
defined at compile time.

My instincts yesterday told me that after a while it would become
apparent that more and more Set-type methods would be necessary but I
have to admit that having given a little more thought I can't really
think of too many. 

As you stated above, the drawbacks of the property mechanism are:

1) Can't easily enforce security policy.
2) Ability to send multiple properties at once.
3) Mapping to ioctls

Regarding 1), I'm not really sure about using D-BUS's security policy to
enforce here is quite the right thing to do. What would be nicest is if
D-BUS could send the UID of the caller when a message is sent to the
service, at least on the system bus. Then, HAL could test the UID
against the relevant property.d script so the distro would be
responsible for deciding policy simply by setting file permissions.

Regarding 2), yes, this is a bit of an issue. Currently, the key naming
implies a sort of tree hierarchy, for example, 'info.*',
'net.wireless.*' and 'net.wireless.network2.*' are different nodes on
the property tree and what we really want with point 2) is that one
should not be able to set just one of the leaves on under a given node
of the tree. Perhaps the problem would be easier to solve with
properties if the tree tree structure were actually represented in
objects. I don't know. Just a though.

Regarding 3), I don't really have any thoughts here.

Ok, it's weekend and I'm going home early. Perhaps I can come up with
something more constructive after weekend :)

Cheers,
Owen



_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal