Correction:
instead of libfreerdp-app, I think I should have said a new virtual channel
plugin named rail instead, written just like any other virtual channel
plugin. In any case, this virtual channel plugin must have a way of letting
the UI register callbacks, such that the UI can write the "extra part".
On Tue, Jun 14, 2011 at 12:08 PM, Marc-André Moreau <
marcandre.mor...@gmail.com> wrote:
> 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
