Good day, Jay.
On Tue, Jun 14, 2011 at 09:47, Jay Sorg <jay.s...@gmail.com> wrote:
> > 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?
>
>
Hum, if it's in the core how are you going to add the extra code?
> I see no benefit to the code being on the core.
> There are several ways to do this.
> 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.
>
> There is not much to the network part of this extension. I don't
> think much is gained here in common code but we can do this in the UI.
>
> > 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?
>
> I don't think your design is best, you don't think mine is. I think I
> should put together some code to show what I am talking about.
>
> One dynamic that is very important to me (and a company that really
> really wants this) is that I need to proxy this with xrdp. If you
> build the channel into libfreerdp, I will for sure have to maintain a
> fork for this. I need the channel in the UI for this to work.
>
Main reason to put them together into the core - RAIL by design is
combination of core protocol extension and virtual channel additional.
They have common cache of windows, icon, notification information.
And identifiers in additional channel refers to identifiers which received
in core protocol orders.
Generally:
- we have UI events from server to UI frontend (new windows, new icons, new
notifications etc)
- we have UI events for server from UI frontend (program launching, local
windows movement, resizing etc)
So we can add interface in freerdp library for UI communication and hide
protocol details from UI.
So every UI can registering their callbacks and can send their UI events to
server in more general way.
I think in this concrete situation additional plugin layer just add more
complexity because we need to create additional
method for "core<->plugin" communication.
How can plugin can communicate with freerdp core structs which received in
core ?
How core can communicate with plugin structs which received in plugin
channel?
I just add channel support into the core and in this way we can reuse all
existing code for channel communication.
Best regards,
Roman Barabanov
------------------------------------------------------------------------------
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
