On 08/12/2015 04:36 PM, Thiago Macieira wrote: > On Wednesday 12 August 2015 14:26:26 Robert Griebl wrote: >>>> Every LoggingCategory (In DLT it's called Context) needs to have a 3 >>>> characters long unique identifier and a Description. >>> >>> Stupid API limitation. Can you convince GENIVI to get rid of the >>> 3-character identifier requirement? It should be an arbitrarily-long >>> string, in which case we can use the logging category itself. >> >> Again - calling other APIs stupid does not help. And no - this is an >> industry standard which cannot easily change, because Qt has a different >> logging API. Besides: have you tried yet to get changes into Genivi >> components? Good luck with that -- we tried to fix a few much bigger >> problems upstream and it ended in uphill battles you don't want to fight. > > This and... > >> >>> qt_hash(the category name) then base64url-encode the result and cut to 3 >>> characters. >> >> And this will be (a) unique and (b) human readable in the DLT viewer? >> (yes even 3 characters can be human readable) > > ... human readable do not go hand-in-hand. If you have 3 letters for a whole > bunch of categories, then by definition it's neither unique nor human > readable. > So my suggestion seems right on the money and it's reasonably unique -- it > provides for 18 bits of data, while most 3-letter human text is around 15 or > 16 bits. > > Another option is to split the category name by the dots and select the first > letter of each section. So "qt.qpa.windows" is "qqw", while > "qt.widgets.gestures" is "qwg".
Using that approach i'm already getting 4 clashes of the 10 categories we use in one of our projects, so i don't think this is the best approach to this. And for me that also sounds like magic which no Qt User would understand, how do you think to document that ? > > You can also add a configuration item to the environment variable or > qtlogging.ini, which provides a separate, shorter name. QtGeniviExtras could > provide an API to set it programmatically. Ok but once you forget to provide the env variable or the logging ini all your logging is lost as DLT don't accept logs without a category. Also this looks like something which is suitable for a developer, but not for a production system. The DLT logging is not something which is disabled in the production. > > But this starts with writing a DLT backend inside QtCore first. Looking at how the logging backends are currently integrated in qtcore this sounds like the worst solution of all, as it needs a configure time check to enable the DLT logging and it would enable it for all Qt libraries and examples. For development this seems to be very unhandy. > >> > By the way, doesn't GENIVI require systemd and thus journald anyway? >> > Why do they have their own logging mechanism? >> >> Did you read the part about the back-channel from the DLT-Viewer to the >> application. But that is besides the point: DLT is used in much more >> than just systemd based IVI systems: > > That's where my ignorance of DLT is. I was assuming it was created by GENIVI, > recently. You're telling me it's an old protocol. > I think it was one of the first GENIVI components and GENIVI is around for quite some years. I doubt that it's likely that they will the protocol. I think the back-channel is really one of the things you can't or better you don't want to do in a qtcore backend. Thiago i totally understand what you are up to and i agree that it would be good if it could be easily integrated as a logging backend. But in my opinion this is really unpractical, it introduces some magic and a special configure time check. IMHO the users of QtGeniviExtras and the DLT logging are totally aware of how the system works and want to have full control over it. DLT is only known in the automotive space and there it's only used for GENIVI linux based systems. So i think we talk about a logging solution which 90% of the qt community don't know or won't ever use. I really don't think this is something which should be integrated into qtcore, and should be totally fine to live in it's own repository and in the end it's very similar of what the other extra repositories currently do, components which doesn't fit and are platform specific are in extras -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holl...@pelagicore.com www.pelagicore.com _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development