GSoC idea

[Sebastian Sauer]

On 02/24/2012 09:41 AM, Kevin Krammer wrote:
> On Friday, 2012-02-24, Sebastian Sauer wrote:
>> On 02/23/2012 05:59 PM, Boudewijn Rempt wrote:
>>> On Thursday 23 February 2012 Feb, Smit Patel wrote:
>>>> On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer<mail at dipe.org>   wrote:
>>>>> **
>>>>> On 02/23/2012 01:31 PM, Smit Patel wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'd like to propose a GSoC project. Here's the brief description about
>>>>> project idea.
>>>>> Provide a dbus API that provides an generic interface that can be used
>>>>> by external bibliography engines (xbiblio, kbibtex, bibus)
>>>>>
>>>>>
>>>>> dbus is optional[1] and so would be everything that depends on it. So,
>>>>> why dbus? Why not just a plugin? If it should be in another process
>>>>> (stability, long-running things, shared among Words-processes, etc)
>>>>> then why not for example QLocalServer?
>>>> If dbus is not available for windows and OSX then we can rule that out.
>>> Well, actually dbus _is_ available on both Windows and OSX.
>> 1. re Windows; Not per default what means you need to ship your own
>> version of it in the installer. If any app does that then it completely
>> voids what dbus is for.
> This is mainly a packaging question.

I think that would would improve the situation for software that is 
requiring dbus.

However I think it's not direct related to the problem named in point 1. 
The main part was about Windows already having IPC that is used by 
Software there we maybe would like to communicate with and cannot with 
dbus. What would really rock is if someone gets support for Windows IPC 
into dbus so dbus could be used for such scenarios.

In Calligra I do not see that we have any use for dbus. We just don't. 
Also if I look around the KDE software-landscape I have hard times to 
find software that really requires dbus and where a port to Windows 
would make sense. I think Kontact was such a case but then with Akonadi 
that's obsolete too afaik.

The ideal solution, in my opinion, would be a slim-IPC layer on top of 
dbus. So, something that does not provide the full richness dbus allows 
but only covers simple use-cases. Such a layer could then use dbus on 
Linux, "WinIPC" on Windows, those Notification-thngs on OSX and whatever 
is available on other platforms.

> I think even on Linux each D-Bus client
> has an (indirect) dependency on the D-Bus daemon.

Compile-time cause of the headers or what you mean with "on the daemon"?

> The Windows way of doing this kind of shared dependencies seems to be to
> include an installer for the shared component which either checks if it has to
> perform its task or the main installer checks if it has to run the component
> one.

Yes. that's how e.g. .NET is handled.

>> 2. re OSX; my knowledge is a few years old but back then when I hacked
>> on dbus making it running at>=Vista I did not found a single line of
>> code that handles OSX. But I can imagine that it changed meanwhile. In
>> any case I doubt it's well maintained and it definitively is not straith
>> forward to work on that code-base.
> My guess would be that it is the exact same code as on Linux, OSX does have
> Unix domain sockets, doesn't it?

I just had a look and indeed support for OSX >=10.4 exists. But I doubt 
it's in a good state. Well, OSX-hackers are hard to get for such kind of 
tasks ;)