#72 generic plugin loader

closed-rejected
nobody
None
5
2005-06-30
2005-06-20
Anonymous
No

This patch provides a generic plugin loader interface
which loads plugins stored as executables and
communicates with them through a plugin protocol over
unix sockets.
Documentation on using the interface is included in
.pdf and .doc format and the source code is available
as patch and as patched rdesktop source tree.

Comments and suggestions are welcome at mingy@hlw.co.at
Submitted by: peter@hlw.co.at

Discussion

  • Peter Åstrand

    Peter Åstrand - 2005-06-29

    Logged In: YES
    user_id=344921

    It's better to post a real patch (against the latest CVS
    version) than an entire source code copy. Also, please avoid
    file names with spaces.

    I'm a bit curious about the purpose of this patch: What
    types of plugins do you expect? I must admit, the purpose
    seems very much to be to make it possible to integrate
    non-GPL code with rdesktop. I'm not saying that this is bad
    thing, but it's a big decision.

     
  • Peter Honeder

    Peter Honeder - 2005-06-29

    Logged In: YES
    user_id=1299886

    The tar.gz contains a patch file (vcp.patch) against a
    recent cvs version of rdesktop, the full sources are only
    provided for reference.

    The patch can be used for various kinds of plugins, this
    includes disk, sound, printer, scanner,... applications.
    Extending rdesktop with virtual channel plugins which are
    not GPL is possible with the patch, but extending rdesktop
    itself with functionality which is not GPL is not possible
    and not intended with the plugin loader mechanism. In my
    opionion this would not be easily possible anyway.
    I think especially in the area of virtual channel plugins
    this patch provides a good base for providing better
    connectivity to windows and an easier handling from the user
    side of rdesktop.

    If I can help with integrating as well as futher
    information, documentation, sample plugin or other resources
    please contact me.

     
  • Peter Åstrand

    Peter Åstrand - 2005-06-29

    Logged In: YES
    user_id=344921

    Disk, sound and printer redirection is already present in
    rdesktop. I agree that it should be as easy as possible to
    add handlers for new virtual channels, but using external
    processes looks clumsy, I think.

    If we really should implement a plugin functionality, why
    not use dynamic loadable modules? glib includes a
    cross-platform implementation.

     
  • Peter Honeder

    Peter Honeder - 2005-06-29

    Logged In: YES
    user_id=1299886

    Besides of the idea of beeing able to use non GPL plugins
    there is a major advantage of external plugins, because they
    can crash and die without having problems. As the virtual
    channel does not directly influence the rdp protocol it
    would be a lot easier to have safe extern virtual channel
    plugins (especially for tasks which result in I/O operation
    like disk access, access to special hardware devices,...).
    It is also important to note that a virtual channel plugin
    could be executed with other rights (setuid bit) this way,
    which might be very important for plugins which need access
    to device drivers or create device nodes.

    Additionally the advantage is, that it enables independent
    software vendors to provide virtual channel plugins which
    are not GPL. This approach still leaves all the rdesktop
    core as GPL source code and at the same time provides a
    useful interface for solutions which are not compatible with
    the GPL license. If someone wants to publish his virtual
    channel software under the GPL he would not be limited in
    any way (anyone else would probably implement such an
    interface anyway on his own).

     
  • Peter Åstrand

    Peter Åstrand - 2005-06-30

    Logged In: YES
    user_id=344921

    The rdesktop development team has decided to reject this patch.

     
  • Peter Åstrand

    Peter Åstrand - 2005-06-30
    • status: open --> closed-rejected
     
  • Peter Honeder

    Peter Honeder - 2005-06-30

    Logged In: YES
    user_id=1299886

    may I ask why?

     
  • Peter Åstrand

    Peter Åstrand - 2005-06-30

    Logged In: YES
    user_id=344921

    >may I ask why?

    Of course. It's basically the things we have already
    discussed in this tracker:

    We don't really see the gain. Using external processes for
    handling virtual channel communication is clumsy; the idea
    does not adhere to the Keep it Small and Simple principle.

    The possibility to create non-GPL plugins is considered a
    drawback. We don't expect that such functionality will
    benefit the rdesktop project in the long term.

     
  • Peter Honeder

    Peter Honeder - 2005-06-30

    Logged In: YES
    user_id=1299886

    I think the advantages of the executable in terms of
    flexibility when using device nodes or handling privileges
    is outstanding compared to the dlopen mechanism (e.g.
    setuid, privileges, compatibility, exception and error
    handling). And the code is effectivly not more than using
    dlopen.

    Although I still think it has many disadvantages to have the
    dlopen plugin mechanism, would you accept a plugin loader
    like this which uses dlopen instead of exec? If yes I would
    submit one during the next week (but I can use my time
    better if you don't accept it anyway).

     
  • Matt Chapman

    Matt Chapman - 2005-07-01

    Logged In: YES
    user_id=60189

    Hi Peter,

    Can you tell us more about what you're trying to achieve,
    and why it would be better maintained as a separate module
    rather than part of rdesktop? This might help clarify
    things. We'd rather not add APIs just for theoretical reasons.

    Matt

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks