[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rdesktop-devel
Subject:    [rdesktop-devel] [ rdesktop-Patches-1472969 ] Patch to add API for
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2008-12-13 22:31:14
Message-ID: E1LBd10-0001xI-GB () 1bkjzd1 ! ch3 ! sourceforge ! com
[Download RAW message or body]

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: Open
Resolution: None
Priority: 5
Private: No
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: 2008-12-13 22:31

Message:
I updated the patch to fix a couple of issues involving an incorrect
calculation of the buffer size and response handling. Thanks to "uIm" for
pointing them out.

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2008-12-13 22:29

Message:
File Added: oop.patch

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2008-12-13 22:19

Message:
File Added: oop.patch

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2008-11-19 09:34

Message:
Hi all

Has anyone had a chance to look at this yet? I have had five queries from
other people asking about the status of virtual channel support recently,
so there does appear to be interest in this patch.

Thanks

Simon

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2008-10-02 23:58

Message:
I have (finally) made the modifications to implement the out-of-process
solution previously agreed upon. In order to maintain the visibility of
whole data blocks now that external add-ins will be responsible for reading
data from the pipe, data written to the pipe is prefixed with a 4-byte long
integer which identifies the block size. The external add-in reads 4 bytes
first, then the appropriate number of bytes before processing the inbound
data.

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2008-10-02 23:55

Message:
File Added: oop.patch

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-03-29 10:01

Message:
Logged In: NO 

Hi...can anyone advise on this please? I don't want to implement something
which will be unacceptable from an architectural perspective.

Thanks

Simon

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2007-12-30 17:33

Message:
Logged In: YES 
user_id=1368449
Originator: YES

I have this functionality almost ready for release (finally), however it
is currently not doing a select() and buffering for writes out to the
add-in. I am aware that this will cause rdesktop to hang if there's nobody
listening at the other end of the pipe...however, I'm not sure how I can
buffer and try later.

I have implemented a generic callback in channels.c which is registered
for each addin. I've modified the callback mechanism so it also passes the
name of the virtual channel in as a parameter to the callback.

When data arrives down a virtual channel for an add-in, the generic
callback uses the vc name to identify the write pipe into which to drop the
data.

If I use select() and decide not to write the data, I can add it to a
buffer but how do I then retry later? Even if I add something to the main
loop which checks if there is any buffered data waiting to send to add-ins,
it will only get called when rdp events occur, otherwise it will just sit
in rdp_recv.

What is the behaviour we *really* want here, and how do I achieve it? The
real problem is not how to identify whether the write would block, but
rather how we manage to deliver the data in the long run.

Thanks

Simon

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2007-08-14 16:03

Message:
Logged In: YES 
user_id=1368449
Originator: YES

> Can someone indicate what the status of this effort is? I see the
original
patch but not any code that implements the consensus approach.

Sorry, this has been on the back burner. Looking to submit a new patch
(for the current rdesktop version) shortly.

Simon

----------------------------------------------------------------------

Comment By: Bob Pesner (bpesner)
Date: 2006-12-15 19:45

Message:
Logged In: YES 
user_id=899391
Originator: NO

Can someone indicate what the status of this effort is? I see the original
patch but not any code that implements the consensus approach.

Thanks

----------------------------------------------------------------------

Comment By: Peter Åstrand (astrand)
Date: 2006-06-07 11:23

Message:
Logged In: YES 
user_id=344921

>So I guess I'm not really opposed to the the separate
>process solution

Good. Everything's clear for implementing this solution, then. 

----------------------------------------------------------------------

Comment By: Matt Chapman (matthewc)
Date: 2006-06-07 10:54

Message:
Logged In: YES 
user_id=60189

Thinking about it some more, I guess the virtual channel
protocol really is just read/write like on a pipe... so the
protocol between the parent and child is pretty simple, and
this avoids any problems with the child having to interact
with the parent's select loop.

So I guess I'm not really opposed to the the separate
process solution...


----------------------------------------------------------------------

Comment By: Matt Chapman (matthewc)
Date: 2006-06-07 10:46

Message:
Logged In: YES 
user_id=60189

In my opinion, this should be a decision on technical
grounds rather than legal ones.  GPLv2 doesn't specifically
address what constitutes a derived work.  I'm not sure I
agree with the FSFs take on this: to me the process boundary
makes no difference, as long as the interface is clearly
defined.  A separate process that uses a complex private API
isn't useful without rdesktop, unless you write another
program that uses the same private API, and you can equally
well write another program that uses the same library interface.

I think either way it would be good to add a licence
clarification.  Contacting all the past authors may be a
challenge, but getting copyright assignment from the past
minor authors is probably something that we should do
anyway, to improve defendability of the copyright, as
recommended by the FSF. The vast majority of the rdesktop
code is copyrighted by a small number of people.

Moving on to the technical side of it, I can't say I'm a big
fan of mandating a separate process.   I think for the
majority of channels it's overkill (look at lspci for
instance, which would be good to move into a plugin, here
basically the intermediate process will just be translating
the output of lspci... perhaps lspci isn't a typical example
though).  FWIW Windows virtual channel plugins are usually
DLLs running in the MSTSC address space.

Are there good technical reasons for the separate process
solution?


----------------------------------------------------------------------

Comment By: Peter Åstrand (astrand)
Date: 2006-06-07 09:33

Message:
Logged In: YES 
user_id=344921

You have my and Pierres support, but Matt has the final word. 

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2006-06-07 09:27

Message:
Logged In: YES 
user_id=1368449

Hi guys

I have been away for a while so haven't looked at this. I
would like to make a start soon at doing the out-of-process
solution to this, as we were discussing. Is this OK, or is
it still a problem? As per my previous comment, the GPL FAQs
seem to back the "out-of-process plugin" option.

Thanks

Simon

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2006-05-08 10:36

Message:
Logged In: YES 
user_id=1368449

Pierre

One of the GPL FAQs specifically talks about what is and
what isn't a plugin: 

http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF

It sounds as if the out-of-process option satisfies the GPL
from this point of view without a problem.

Simon

----------------------------------------------------------------------

Comment By: Pierre Ossman (ossman_)
Date: 2006-05-08 07:58

Message:
Logged In: YES 
user_id=1469081

My point was that implementing a plug-in API over a pipe
instead of function calls doesn't magically free you from
GPL's obligations. If you check clause 2 it talks about
independent parts and not about specific technical boundaries.

My personal opinion, though, is that you'd have to transfer
more complex data structures over the pipe before the
"plug-ins" would be covered by GPL. Others might think
otherwise, so we should check that we don't step on too many
toes when implementing a function like this. Hence my "It's
by no means clear..." comment.

----------------------------------------------------------------------

Comment By: Ilya Konstantinov (ikonst)
Date: 2006-05-08 07:51

Message:
Logged In: YES 
user_id=335423

Brad, you can do a mental exercise and see that any shared
library can be turned into an external process with a
stream-based protocol. In this case, we're the network
carrier and the virtual channel providers are the network
applications. This is equivalent to libssl + application.
Aren't SSL libraries needing to be LGPL'd to be used by
non-free software? Sure they are! How is rdesktop different?

----------------------------------------------------------------------

Comment By: Brad Hards (bradh)
Date: 2006-05-08 07:40

Message:
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?  

----------------------------------------------------------------------

Comment By: Pierre Ossman (ossman_)
Date: 2006-05-08 07:18

Message:
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.

----------------------------------------------------------------------

Comment By: Ilya Konstantinov (ikonst)
Date: 2006-05-06 11:18

Message:
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.

----------------------------------------------------------------------

Comment By: Peter Åstrand (astrand)
Date: 2006-05-06 10:52

Message:
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:]...]


----------------------------------------------------------------------

Comment By: Peter Åstrand (astrand)
Date: 2006-05-06 10:48

Message:
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. 

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2006-05-06 09:36

Message:
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

----------------------------------------------------------------------

Comment By: Peter Åstrand (astrand)
Date: 2006-05-06 08:48

Message:
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. 


----------------------------------------------------------------------

Comment By: Brad Hards (bradh)
Date: 2006-05-05 23:46

Message:
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. 

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2006-05-05 21:48

Message:
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?

----------------------------------------------------------------------

Comment By: Ilya Konstantinov (ikonst)
Date: 2006-05-05 20:44

Message:
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.

----------------------------------------------------------------------

Comment By: Alon Bar-Lev (alonbl)
Date: 2006-05-05 20:29

Message:
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).


----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2006-05-05 20:20

Message:
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. 

----------------------------------------------------------------------

Comment By: Ilya Konstantinov (ikonst)
Date: 2006-05-05 20:09

Message:
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".

----------------------------------------------------------------------

Comment By: Simon Guerrero (incarnis)
Date: 2006-05-05 19:53

Message:
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... :-/


----------------------------------------------------------------------

Comment By: Ilya Konstantinov (ikonst)
Date: 2006-05-05 19:25

Message:
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".

----------------------------------------------------------------------

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

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
rdesktop-devel mailing list
rdesktop-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdesktop-devel

[prev in list] [next in list] [prev in thread] [next in thread]