#107 Patch to add API for Virtual Channels
This patch makes the virtual channel capability in
rdesktop visible to third parties, so that applications
which extend RDP using the virtual channels can "plug
in" to rdesktop by supplying a shared object.
A new variant of the "-r" option has been implemented,
namely:
-r soname.so:opt1:opt2:opt3...optn
where soname.so is the name (fully qualified if need
be) of the third party shared object. opt1 to optn are
optional arguments which will be passed to the shared
object if needed.
The API is implemented as follows:
* All third party shared object must implement two
named functions, rdesktop_init and rdesktop_cleanup.
* A new function called "init_external_vchannel" has
been added to channels.c. Whenever a shared object is
specified in the parameters, a handle is opened using
dlopen and this handle is added to an array for use
later. The rdesktop_init function is located and
called, passing in the addresses of the virtual channel
functions in rdesktop (channel_register, channel_init,
channel_send) and any arguments which were passed in on
the command line. The third party app can then use
these functions to send and receive data on virtual
channels, just like sound, cut and paste etc. The
rdesktop_cleanup address is then located and stored.
* At the end of the RDP session, rdesktop calls the
rdesktop_cleanup function for each third party shared
object.
Patch to add virtual channel API
Logged In: YES
user_id=344921
A mechanism like this one has been discussed and also
rejected before. Using plugins this way violates the GPL,
unless the plugin is also GPL (or compatible). In that case,
it's better to submit it for inclusion into the rdesktop
project.
Logged In: YES
user_id=1157530
Hello,
Just wanted to note that the same issue exists with kernel
models... And we have modules.
And why bother... One can get the source of rdesktop and add
whatever he wishes and violate GPL.
This is not a good reason why a plugin interface should not
be added.
Best Regards,
Alon Bar-Lev.
Logged In: YES
user_id=344921
>Just wanted to note that the same issue exists with kernel
>models... And we have modules.
But not without problems. For example, the kernel has a
"tainted" mechanism, which can show if you have loaded
binary-only modules. This patch contains no such support, right?
>This is not a good reason why a plugin interface should not
>be added.
The question should rather be: "Why *should* a plugin
interface be added?". Why isn't it acceptible to contribute
the plugins you are developing to the rdesktop project?
Logged In: YES
user_id=1469081
The comparison to kernel modules is flawed. Kernel modules
are there to reduce the footprint of the kernel, not to
allow out-of-tree drivers. Like this project, the Linux
project does not cater to external add-ons (which is why
the kernel doesn't have a stable module API). It adds
complexity and reduces flexibility, so you need to present a
strong case for setting up such a system.
Logged In: YES
user_id=1157530
Well... I thought the kernel is a good known example... But
there are many more GPLed projects with plugins... But it is
your call. I think that virtual channel is a good example
where such interface is required... But I understand your
position to merge all into your project.
Logged In: YES
user_id=1368449
Hi
I submitted this patch after long discussions with Matt
Chapman, who suggested this means of exposing the virtual
channel functionality.
While I understand the suggestion this is a way of getting
around the GPL, and everyone who wants to add something to
rdesktop ought to make their code open source too, I don't
agree. The ability to expose the virtual channel
functionality is a fundamental component of Citrix and RDP
on Windows, for example, and as a result there are multiple
commercial users of Citrix (and RDP) who have produced
commercial offerings to add functionality which isn't
natively available in those technologies as they stand.
While I would agree wholeheartedly that new technology
developed purely to extend rdesktop should naturally be
GPL'd, I would point out that there are a huge number of
commercial Windows products for RDP virtual channels which
simply aren't being implemented on Linux because they don't
want to go ahead and GPL all their code. And because they
don't make it available for Linux, customers go with
Windows solutions. Or providers of the technology go ahead
and violate the GPL - which is what some of my commercial
clients will just go and do if they don't have this. I know
because that's what they wanted to do first.
I would be glad to discuss technical issues with this
solution to make it technically "good", as I really think
rdesktop is missing this. But I think rejecting it out of
hand because it might encourage people to create non-GPL
virtual channel solutions is taking a pretty narrow view,
IMHO.
Simon
Logged In: YES
user_id=335423
Since rdesktop is licensed under the GPL, rather than under
the LGPL, it would be illegal to make rdesktop link, even in
runtime, with a non-free virtual channel shared library.
rdesktop could be relicensed but since there wasn't any
copyright assignment process, the authors of every bit of
code we have would need to agree to that. (Correct me if I'm
wrong on any of the above points.)
Do we already have any ISV who'd produce a non-free plugin
as soon as this API goes in, or is the market you describe
theoretical?
Last but not least, I feel that adding non-free code into
the process space of rdesktop would be disadvantegous for
us, the users and the developers. Instead of seeing this as
"we'll benefit once we'll have non-free feature X", one can
see it as "they're bribing us to give up the convenience
we're used to, in exchange for the "opportunity" use their
product".
Logged In: YES
user_id=1368449
I've had a long, close look at the GPL (including the
FAQs), specifically with regard to plugins, but the way I
see it is this:
Basically, this change isn't the "classic" plug-ins case
(modifying rdesktop to work with a specific non-free app by
means of dynamic linking). This is allowing rdesktop to
take on the functionality of the very technology it was
reverse-engineered from ( another thorny legal issue ;-] ).
RDP on windows includes a virtual channel API - it's part
of RDP. But like I say, this is IMHO. I know this is
frequently argued elsewhere.
With regard to the market for this, I have two real names
of real ISVs who are desperate for this - one of whom is a
seriously big player, with a contract to supply for a
10,000+ user base. I don't think they'd be happy with me
posting their name as I'm under an NDA with them for other
Linux work, but they are big, and they were all set to just
violate GPL on this.
Regarding your final point about "bribing us to give up our
convenience for the opportunity to use their product" -
that's an alternative view. But I figure if companies
really start doing that kind of thing with rdesktop, as
soon as a useful non-free plugin appears that gets
reasonably popular, you can bet someone will create a GPL
version of it. I see it only doing good.
I didn't intend to get the "everything should be free"
community up in arms with this change. I was kind of hoping
to implement something that would keep everyone
happy... :-/
Logged In: YES
user_id=335423
If there wasn't enough community demand for a free
implementation for this ISV's plugin, why would a non-free
implementation create that demand? After all, the demand
steems from server installation of the said product (which
requires said modification to RDP clients). And it's not
like a rdesktop-based plugin is easier to reverse engineer...
How about they work *with* us instead, and have their
client-side part built-in in every Linux distro around?
Regarding leveraging functionality from mstsc, that
functionality being "Virtual channel API", cool - but we
cannot leverage the licensing terms at the same opportunity;
we cannot make rdesktop legally eat non-GPL plugins.
As to reading the "language of the license" and figuring out
what the GPL authors intended, I think they pretty much saw
it coming. The naive approach is to think of the GPL as a
protection against "don't make a small improvement and
release it as yours, non-free". However, the real scope of
the GPL is also about "we strive so all software we use will
be free cause it's useful to us and makes our lives more
comfortable -- we have a vested interest in that; chose our
side of the fence and benefit from our assets".
Logged In: YES
user_id=1368449
The ISV we're talking about doesn't have "community demand"
- it has a userbase on Windows clients that it wants to
supply with Linux-based ones instead. In fact, both ISV's I
am specifically aware of have the same requirement.
The problem is not with them not wanting to have their
client-side work shipped with every distro - I'm sure they
love that idea. The problem is that by making the Linux
versions of their existing Windows virtual channel
extensions open source, they expose critical details of
their protocol implementations and "tricks" which loses
them their commercial advantage over all platforms. I'm not
just guessing at this - this is why the need for this kind
of API arose.
With regard to the licence - other GPL'd apps have got
around this by adding an "..except for plugins" clause to
their licence text. But I see how that would grate with
some of you guys.
I really do think this is *missing* functionality from
rdesktop. It's part and parcel of RDP client functionality.
Logged In: YES
user_id=1157530
The whole point of rdesktop is to provide a free open-source
RDP client.
I as a user think this is an important advantage... Providing some
of the functionality in binary form is not something we want to
encourage.
So if the intention of the plugin patch was to bypass the GPL it is
indeed bad idea.
When I first commented in favor of the plugin interface is to allow
GPLed plugins to work with rdesktop.
Using none GPLed plugin designed specific for GPL application
is GPL violation. It is exactly as taking the rdesktop code and
adding a propreitary code. When someone chooses to violate the
license of open-source application he can do that very easily,
with or without a plugin interface.
An exception of this is a plugin like a PKCS#11 provider which is
not application/implementation specific that may be loaded by
GPL application (I had a long discussion with FSF regarding this
issue).
Logged In: YES
user_id=335423
Re "exception clause": That is indeed possible, if each and
every person whose lines of code reside in rdesktop would
agree. When we checked in code supplied to us by
contributors, we never asked them to assign copyright to any
single body.
Re "part and parcel", indeed - Virtual Channels and
extensibility are an integral part of the RDP architecture.
However, mstsc's licensing model is not, so it's not obvious
that we should leverage it just as we leverage mstsc's
technical features.
I'm not convinced that distinct virtual channel
implementations are a case of "linkage", rather than a case
of "program running on a platform", and if so, that it
couldn't be made under the terms of the CURRENT license.
This might deserve another thought. However, I am convinced
that the proliferation of non-free virtual channel
implementations is against my personal interest in the long run.
Logged In: YES
user_id=1368449
I figured the exception clause would be OK, since copyright
notices appear (to specific individuals) at the top of each
piece of source code!
I agree absolutely and without reserve that proliferation
of non-free VC apps is a _bad_ thing. But I think that
support for existing non-free VC apps to encourage the
proliferation of Linux-based thin clients to be a good
thing.
If we take it as given that ISV's won't want to make their
VC app implementations public, is there any way out of
this?
Logged In: YES
user_id=13687
I think it is going to be a problem having it in-process.
Perhaps the interface could be changed to take an
out-of-process handler (unix domain socket, file
descriptor or something like that), and run the third
party code in a separate process.
Logged In: YES
user_id=344921
bradh, I agree. I was just about to write the same when I
saw your comment. I think an out-of-process solution would
solve most issues:
* It's fine with GPL.
* The extension cannot interfere with the rdesktop
internals, so the extensions would be limited to virtual
channels stuff.
Using the "inetd" approach (connect stdin/stdout to the
channel) looks ideal.
The only problem left is that this *might* mean that closed
extensions are being developed/deployed instead of open
ones. I can accept this risk, though.
Logged In: YES
user_id=1368449
Thanks for all your feedback. I want to make sure I
understand this (it's been a long week).
* A user would specify an executable name as a parameter
* Rdesktop would open a pipe, then fork and exec
* Read and write from pipe to use the VC
I guess this means that incoming data on the channel won't
act like a 'callback' - the external app would have to keep
looking to see if there's any data. Or am I missing something?
This sounds good for me for other reasons too - the
in-process solution has another disadvantage that I just
figured out.
When the "process" function in the external .so gets called,
it will hang rdesktop until completion (unless the app kicks
off a thread and returns). This means that rdesktop can't
interact with the rest of the X system until its event loop
is given a chance to come back. Out-of-process would get rid
of this issue too.
I am happy to go away and redesign based on this. Can you
guys please give me some ideas of how you think this should
be done?
* Currently it uses the -r option and looks for an arg
ending in .so. Should I define a new -arg?
* Any other ideas?
Simon
Logged In: YES
user_id=344921
>* A user would specify an executable name as a parameter
>* Rdesktop would open a pipe, then fork and exec
>* Read and write from pipe to use the VC
Yes.
>I guess this means that incoming data on the channel won't
>act like a 'callback' - the external app would have to
>keep looking to see if there's any data. Or am I missing
>something?
Something like this, I think: When rdesktop recieves new
channel data, it should write the data to the pipe, assuming
the pipe is ready. We can use select() for this. If the pipe
is not ready for writing, rdesktop can buffer until it's
ready. rdesktop should also monitor the pipe for reading:
When it's ready, rdesktop reads from the pipe and writes to
the channel.
The "addin" process can also use select(), if necessary, or
simply use blocking reads and writes, if allowed by the
protocol.
>* Currently it uses the -r option and looks for an arg
>ending in .so. Should I define a new -arg?
One idea is:
-r addin:channelname:/path/to/executable
I'm using the "addin" keyboard, since that's what MS calls
the client DLLs.
Another possibility is to let the executable define the
channelname. Then it would suffice with:
-r addin:/path/to/executable
This could be implemented by having the executable writing
the channel name (and possible some other initialization
information) to stdout. One drawback with this approach is
that we are no longer following the simple inetd model, so
it would not be possible to re-use plain inetd servers. So,
I think the first variant is preferred. (This would allow us
to use servers like Samba over a virtual channel. Pretty
cool, but of course you'll need support on the server end as
well.)
>* Any other ideas?
There's already some code in rdesktop for forking and
reading from a subprocess. Perhaps it can be re-used. The
lspci should perhaps also be moved from rdesktop to an
external "addin".
Please note, though: I'm positive to a mechanism like this,
but I'm only speaking for myself, not the entire rdesktop
team. So, we need to have their input as well.
Logged In: YES
user_id=344921
It should probably be possible to pass arguments to the
addin as well. So:
-r addin:<channelname>:</path/to/executable>[:arg1[:arg2:]...]
Logged In: YES
user_id=335423
I believe that, as Gtk+ and Qt have demonstrated, one can
poll both X event queue and other file descriptors in a
single select, so there's no real need for multithreading.
Logged In: YES
user_id=1469081
>bradh, I agree. I was just about to write the same when I
>saw your comment. I think an out-of-process solution would
>solve most issues:
>
>* It's fine with GPL.
>
I'd have to disagree with this point. The GPL does not
mention linking as being the blessed form of creating
"derived" works. In my eyes, a rdesktop specific pipe is no
different from loading an object into the process memory space.
That said, this "API" would be so trivial it might not be
covered. But still, it is by no means clear that it isn't a
GPL violation.
Logged In: YES
user_id=13687
I think it is a bit zealous to consider that the previous
authors didn't want rdesktop to be able to communicate
with a process that isn't GPL'd. After all, that is it
it's primary feature!
Which clause of the GPL do you think would be violated?