Hi Jay,
On Tue, Jun 14, 2011 at 2:47 AM, Jay Sorg <jay.s...@gmail.com> wrote:
> > For 2.2.1 we both agree (they are new secondary orders)
>
> Yup
>
> > 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.
>
The core would handle the network part, and then handle the rest to the UI
via UI callbacks, such that the UI only cares about the "extra code" and
knows nothing of the network code.
>
> > 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.
>
Ok, I understand now that if we make libfreerdp-core register a virtual
channel instead of the UI, it becomes a serious architectural for xrdp
working as a proxy. That makes more sense, I just didn't think about that
before.
Maybe a compromise would be the following:
2.2.1 implemented in libfreerdp-core, since it's new secondary orders
2.2.2 implemented in libfreerdp-app, since it's a new virtual channel
The UI registers the new virtual channel, and makes use of libfreerdp-app
for handling the network part of it. The UI registers callbacks with
libfreerdp-app such that it only cares of the extra part, none of the
network part. Such things include the language bar, which I would easily see
handled by Remmina or any other UI in a separate way. To me, it is very
important that the UI does not deal with network code directly, network code
belongs to another layer in which the UI does not belong.
Would this approach work for both of us? I think the most important for you
is to register virtual channels in the UI, such that you don't get a problem
with trying to proxy an RDP connection using xrdp later on.
Also, maybe you could put down in a drawing what you have in mind, just like
I did last time using google docs (Create New -> Drawing).
I basically want an equivalent of libfreerdp-rfx in terms of software
reusability. I was happy to see that libfreerdp-rfx wasn't highly coupled
with xfreerdp, such that I could adapt it to dfbfreerdp in little time. I
want the same reusability for RemoteApp, which means not having the UI
implement the network code. The network code should be shared by UIs, not
duplicated. We can still do this by having the virtual channel registered by
the UI if we follow a design similar to libfreerdp-rfx.
>
> 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
