[Development] New Module Request: QtGeniviExtras

[Dominik Holland]

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.holland at pelagicore.com
www.pelagicore.com