Hi Jay,
On Tue, Jun 14, 2011 at 2:05 AM, Jay Sorg <jay.s...@gmail.com> wrote:
> > I'm not sure I'm following you, you would prefer to see RemoteApp
> > implemented as a completely separate plugin, just like the clipboard
> plugin?
> > It is pretty much a variant of the core RDP graphical messages, which is
> why
> > I think it should be put in the same place as those messages. What do you
> > suggest exactly?
>
> Hi Marc, I'll try to explain better.
>
> The spec [MS-RDPERP] (unless I have the wrong doc) contains
>
> 2.2.1 Updates to the Remote Desktop Protocol: Basic Connectivity and
> Graphics Remoting Specification
> 2.2.2 Static Virtual Channel Protocol
>
> 2.2.1 should be built into libfreerdp as new secondary orders. This
> includes changes to the UI interface.
> 2.2.2 should be built into the UI (xfreerdp). Not a channel plugin
> but a channel registered by the UI.
>
> I do not think we should try to register channels in libfreerdp.
> The UI already has a clean interface for this.
>
For 2.2.1 we both agree (they are new secondary orders)
For 2.2.2, it contains various things like reporting window movements, the
language bar, events like minimize, maximize, resize, etc.
I agree that we shouldn't register a virtual channel directly in
libfreerdp-core, but if the UI is to register the virtual channel, how is
the UI only going to have to bother to add the extra code necessary to do
the actions following those events?
What I mean by this, is the network part of 2.2.2 should be common to all
UIs, and the UI should only bother implementing the part of code which
either gathers event data, or acts upon events sent by the server, pretty
much like drawing orders are currently handled.
Please describe how you see it, since it would be very helpful.
Personally, I think it should go in the core, but not using the same API as
virtual channel plugins. Maybe we should add support in libfreerdp-chanman
for plugins handled in the core, not as plugins. Otherwise, what would be
the point of having each UI register the RemoteApp virtual channel? I think
we could simply this by having the UI report support for RemoteApp, and then
the core simply enables or does not enable it at the protocol level, just
like RemoteFX is just an on/off switch.
Since RemoteFX support is provided with a separate library, maybe you were
thinking of having the UI register the virtual channel, but then make use of
a new library called libfreerdp-app?
>
> Jay
>
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
