DBus director extension

[Giuseppe Corbelli]

Hi all
I'd be interested in a DBus director extension to control SciTE. I think I can
take care of the development, but of course any help would be welcome.
Is it an interesting feature? Something that has the chance to be merged, I mean.

--
Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net
-<! Non c'e' niente da dire in proposito. Tutto quello che uno deve fare e'
colpire i tasti giusti al momento giusto, e lo strumento suona da solo. !>-
J.S. Bach

[Neil Hodgson]

Giuseppe Corbelli:

> Something that has the chance to be merged, I mean.

It depends on being simple and maintainable and not damaging support for clients of the current pipe-based director.

Neil

[steve donovan]

On Tue, Feb 5, 2013 at 12:52 PM, Neil Hodgson <nyama...@me.com> wrote:
> It depends on being simple and maintainable and not damaging support for clients of the current pipe-based director.

Yes, since pipes work as expected on all POSIX systems, unlike dbus.

A good strategy would be to have director extensions as loaded shared
libraries. SciTE would work just as before, except if a director
plugin is specified, in which case that handles RPC requests.

[Giuseppe Corbelli]

On 05/02/2013 11:52, Neil Hodgson wrote:
>> Something that has the chance to be merged, I mean.
>
> It depends on being simple and maintainable and not damaging support for clients of the current pipe-based director.

Surely it does not make sense to break the current behaviour.
Maybe just adding a DBusDirectorExtension to be registered under #ifdef DBUS
using dbus-glib?

[Giuseppe Corbelli]

On 05/02/2013 11:59, steve donovan wrote:
>> It depends on being simple and maintainable and not damaging support for clients of the current pipe-based director.
>
> Yes, since pipes work as expected on all POSIX systems, unlike dbus.
>
> A good strategy would be to have director extensions as loaded shared
> libraries. SciTE would work just as before, except if a director
> plugin is specified, in which case that handles RPC requests.

True, but this would mean pulling in some plugin loading logic.
Does it bring in much value? Just for a couple of directors?

[Neil Hodgson]

Giuseppe Corbelli:

> Surely it does not make sense to break the current behaviour.
> Maybe just adding a DBusDirectorExtension to be registered under #ifdef DBUS using dbus-glib?

What situations do you see the #ifdef being turned on?

Neil

[Giuseppe Corbelli]

Compile time if the required headers/libs are available.
Right now I don't see extension startup being controlled by commandline
options, so I didn't mention it.

[Neil Hodgson]

Giuseppe Corbelli:

> Compile time if the required headers/libs are available.

I mean: what would lead to someone deciding to turn on the feature?

Neil

[Giuseppe Corbelli]

Completely useless for the "standard" user, I'd say it could be handy for
director developers.
*) Easier to know if an istance is running and to connect it
*) "Standard" way on unix
*) You can have multiple interfaces without searching for multiple FIFOs

In short I think it would be less error prone and easier overall.