From: SourceForge.net <no...@so...> - 2006-05-05 19:13:25
|
Patches item #1472969, was opened at 2006-04-19 13:17 Message generated for change (Comment added) made by incarnis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381349&aid=1472969&group_id=24366 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Simon Guerrero (incarnis) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add API for Virtual Channels Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 19:13 Message: 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 ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 14:44 Message: 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. ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2006-05-05 14:31 Message: 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. ---------------------------------------------------------------------- Comment By: Peter à strand (astrand) Date: 2006-05-05 14:25 Message: 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? ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 14:09 Message: 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. ---------------------------------------------------------------------- Comment By: Peter à strand (astrand) Date: 2006-05-05 13:53 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381349&aid=1472969&group_id=24366 |