Good day, Jay.
On Tue, Jun 14, 2011 at 11:32, Roman Barabanov <romanbaraba...@gmail.com>
wrote:
>
In any case now we have 2 possible variants:
- channel communication in the core. I prefer this way, because it simple
(KISS forever) and already fixed in my private plans.
- channel communication out of core: plugin or other methods. This way
suggests Jay.
Before we make final decision about acceptable place of channel
communication, I continue the process of adding 'rail' channel into core,
but I will keep in mind that all code for 'this'channel can be moved into
the other place.
Best regards,
Roman Barabanov
On Tue, Jun 14, 2011 at 11:32, Roman Barabanov <romanbaraba...@gmail.com>wrote:
> 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
