Am 28.05.15 um 18:19 schrieb Rutledge Shawn: > On 28 May 2015, at 13:35, Marc Mutz <[email protected]> wrote: > >> Please don't overengineer this. If this is about CAN, call it QtCanBus. If >> it's about i2c, call it QtI2cBus. These are separate libraries. You get the >> idea. This is not like the web (ftp, http, ...) where there's an established >> abstraction (URLs) and the vast majority of applications shouldn't care >> about >> the actual protocol underlying a URL (thus, QNAM is ok, even though I note >> that it loses functionality compared to QHttp, just as QHostInfo lost >> functionality compared to QDns). >> >> I don't know about CAN, but taking KNX as an example I know well, you want >> (preferably static, as opposed to type-erased) access to the KNX data >> formats >> and group addresses. Yes, all the way up to QML, not just C++. >> >> QAbstactSocket is listed in the Wiki as a design mistake. >> >> Don't repeat it, please. > Back before URLs were standardized, someone could have objected that it’s too > hard because Windows uses drive letters and colons and backslashes in file > paths, or that network addresses are different between TCP/IP, Novell and > token-ring networks, or that making a namespace for so many protocols (file, > http, ftp, telnet, ssh, gopher etc.) is hopeless. But it got done anyway, > and does anybody think it was a mistake? > > So I disagree that trying to make up a standardized namespace abstraction for > all the buses is necessarily a futile effort. In fact it would be surprising > if nobody had tried by now. > > As a result of the IoT hype, the idea of assigning a URL to a > network-accessible device is inevitable. But now we are talking about the > other end of some bridge device, which translates network requests into local > bus requests. > > Another common abstraction on Unix-like systems is that everything is a file. > One sensor-bus project I’m familiar with is http://owfs.org which is about > communicating with sensors and other devices on one-wire networks, regardless > how those networks are connected. (There are USB adapters and serial-port > adapters for PCs, GPIO hacks on various embedded systems, etc.) The name > comes from the fact that it started with a FUSE daemon to make possible > “mounting” the network and then accessing each sensor as a virtual file: you > can read from a particular path to get the temperature from a temperature > sensor, for example. Which is pretty cool because you need nothing more than > your favorite shell to interact with anything on the network. But pretty > soon the project had defined a network protocol too, and also a way of > accessing the same sensors over http, which means every sensor has a URL too. > “Mounted” networks are served up by a network daemon, and remote > network-accessible sensor buses can also be “mounted” locally. > > A similar thing was done for the X10 and Insteon home automation powerline > remote-control systems: there’s a daemon to handle virtual files for the > devices. (But X10 doesn’t have any discovery capability, so the filesystem > nodes needed to be created in advance.) At my last house I had one-wire and > X10 devices available as “files” on the same Linux box, and it was possible > to do some home automation with nothing more than cron jobs echoing commands > to certain paths. Reacting to button presses from remote X10 panels required > a tiny bit of scripting though. > > Likewise a BlueZ serial link can be pre-configured at a particular file path > so that when you open the “file”, you open a link to that device. > > Of course the /dev/ttyS? tradition started much earlier. RS-232 ports just > need extra out-of-band configuration for baud rate, stop bits, flow control > etc., but otherwise the file abstraction holds. The main reason we have > QtSerialPort is the serial port's lack of automatic configuration, which > newer buses tend to have. > > So to an extent, Qt wouldn't need extra code for communicating with diverse > buses, as long as this tradition of mapping things to the filesystem > continues.
I don't think QtBus actually tries to solve this problem, it's more about the protocol itself used on the Bus. Talking about the CANBus, there is already support for unix file systems to write can messages using file descriptors, but the hard part is to use the right protocol. One project we had some years ago was to get a CANBus connected TouchScreen to work with Qt. There the touchpoints got transfered using 7byte (not 8) integers. Having some classes in Qt which would help reading or writing data to the Bus in the desired protocol would save a lot of work, especially if it can read the protocol using vector dbc files. Dominik _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
