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++. QAbstactSocket is listed in the Wiki as a design mistake. Don't repeat it, please. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development