> On 28 May 2015, at 18:16, Frederik Gladhorn > <[email protected]> wrote: > >> On Thursday, May 28, 2015 01:35:17 PM Marc Mutz wrote: >>> On Tuesday 26 May 2015 15:33:59 Viironen Kalle wrote: >>> For naming we have thought either QtBus or QtSerialBus. IMO name as such >>> should already on it’s own describe the generalised idea of the module. >> >> What use-case do you have in mind where the programmer doesn't know that >> he's talking to a CAN bus? Or an i2c one? Or, for that matter, to a KNX >> bus? >> >> Sure, there are apps that generically will talk to any bus as long as >> there's a Qt plugin for it, but those apps should implement the abstraction >> layer themselves, as fits their needs. >> >> 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++. > > My understanding is that the goal is to be able to share code, in the end we > should still end up with several classes handling specific buses, but also a > shared repository and not re-inventing all of the implementations from > scratch > for each new bus type. > > Cheers, > Frederik
At first the QtSerialport could be moved under QtBus module and built from there (in same fashion as QtPim) as is to keep binary compatibility. I haven't looked the implementation specifics of QtSerialport, but later it could be moved directly under QtBus changed to use plugin backends, while still offering several bus specific classes, as Frederik stated. -Johannes > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
