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 > > QAbstactSocket is listed in the Wiki as a design mistake. > > Don't repeat it, please. > > Thanks, > Marc _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
