kwallet and QCA

[nf2]

Kevin Krammer wrote:
> On Monday 09 June 2008, Michael Pyne wrote:
>   
>> On Monday 09 June 2008, Martin Konold wrote:
>>     
>>> Am Samstag 07 Juni 2008 schrieb nf2:
>>>
>>> Hi,
>>>
>>>       
>>>>>> C++ w/QtCore is also sensible these days.
>>>>>>
>>>>>> * it is part of the LSB
>>>>>> * QtCore has no GUI dependencies
>>>>>>             
>>>>> And before licensing is brought up, let me point out that it's
>>>>> irrelevant if what's implemented is a DBus service.
>>>>>           
>>>> That's a limitation though. Therefore QtCore is only a secondary option
>>>> for platform stuff i think.
>>>>         
>>> Actually there is no limitation. If the service is offered via a DBUS
>>> interface there are zero limitations. On the other hand QtCore offers
>>> much for run-time and development time efficiency.
>>>       
>> It's still bad because it's C++.  C++ is evil.  C is the One True Way to
>> go, well supported by even gcc 2.7! 
>>     
>
> Sarcasm aside, I think that the limitation Nobert refers to is the scope of 
> out-of-process functionality.
> Regarding the thread content, single-sign-on/authentifcation service this is 
> obviously not a problem, 
This might be a overhasty conclusion though. Keyring - for instance - 
seems to require direct socket connections.

> however it might be in a different context where 
> functionality needs to be provided in-process.
>   

Yes - and don't forget that even code being developed for out-of-process 
services could be reused in-process.

> Fortunately we see a move into service based infrastructure from basically all 
> desktop platform providers, so each software stack can provide the kind of 
> protocol implementation that makes most sense within the concepts the 
> developer of the respectice stack are used to (e.g. threaded I/O on stacks 
> like Java vs. event loop based I/O on stacks like GLib/GObject or Qt)
>
>
>   

This sounds all very nice in theory, but i doubt that the "lack (or 
fragmentation) of platform" problem will ever be fixed that way. Maybe i 
am impatient, but i got the impression that this DAPI model just doesn't 
seem to be very successful in practice. Perhaps that's because it's 
putting the cart before the donkey. Things need to be coded, and during 
this process the APIs and interfaces start to consolidate. Therefore the 
first thing necessary for collaboration is a decision on a standard 
programming language, library stack and maybe API style for this layer.

Norbert