On Fri, Jan 12, 2018 at 6:25 AM, Amarjeet Singh <amarjee...@gmail.com>
wrote:
> ...
>
> 1. After more debugging I have noticed that these functions take lot of
> time to process if buffer size if large ( copying or pasting large amount
> of data ).
>
>
> 1.
> *__encode_utf8 *
> 2.
> *__append_utf8 *
> 3.
> *array_writer.sendData(__encode_utf8(text)); *
> 4. *__decode_utf8*
>
>
Can you elaborate here? What leads you to the conclusion that encoding
things to UTF-8 is taking significant processing time?
2. There are many function in Guacamole Javascript which are independent of
> user interface elements, such as the DOM and common JS functions like
> getElementById where we can use Webworker to improve the performance of
> Guacamole.
>
Again, can you elaborate? What specifically do you believe would be
improved through the use of WebWorkers? Have you tried making this change
yourself and observed significant improvement?
3. On Paste event we can get the data from the Local Clipboard and send it
> to the Remote Server so that Remote server also synced with the Local
> Server == And then send the Ctrl + V keys to paste the CLipboard data.
>
The browser will only fire the "paste" event under very strict
circumstances. What you describe can work, but you will run into
difficulties with:
* Differences among platforms between the keys pressed locally vs. remotely
for pasting clipboard data (not all platforms use Ctrl+V, and even on
platforms which typically use Ctrl+V, not all applications will do so)
* The need to allow some key events through to the browser so that keyboard
events blossom into actual clipboard events, yet still somehow take control
of those events to the extent that they can be sent to the remote desktop
unmodified if they do not actually deal with clipboard after all.
This was actually tried in the past, years ago, in much older releases of
Guacamole. The changes were ultimately removed because they proved too
unreliable and confusing for users. Users were confounded when Cmd+V on Mac
didn't work for paste connecting to Windows, or when pasting via Ctrl+V did
nothing when a remotely-running terminal emulator actually required
Ctrl+Shift+V for paste, or when attempting to paste through clicking with
the mouse did nothing.
4. On Copy event We are getting the data from the remote Clipboard and same
> we can send it the Local Clipboard using the Copy event to make both the
> local and remote clipboard synced.
>
Similar to paste, this does not work well in practice. Besides the issues
with keyboard events described above, there are timing issues with
retrieval of clipboard data. There is no guarantee that the remote
clipboard data will be received locally within a reasonable time frame of
Ctrl+C being pressed. Because the clipboard can only be modified during the
"copy" event itself, something must block the main JavaScript thread while
clipboard data is being received. We did exactly this in older releases of
Guacamole, through using synchronous XMLHttpRequest to force the thread to
block while the server awaits clipboard data, but again ran into issues:
* As with paste, the copy event will not occur during remote mouse
interaction.
* As with paste, platform and application differences in keyboard shortcuts
cannot be reliably handled or predicted.
* Synchronous XMLHttpRequest is deprecated and can no longer be relied upon.
5. Main task is to sync the Local and remote Clipboard before copying and
> pasting data.
>
> *My Queries are as follows :- *
>
>
> 3. Can't we send plain data so that we don't have to decode or encode the
> data in Clipboard scenario as it can increase the performance ?
>
>
>
No. There is no such thing as "plain data". For communication between two
systems to make sense (between Guacamole client and server), there must be
an agreed upon encoding for data sent and received. Guacamole uses UTF-8
for transmitted text, and the processing required to transform JavaScript's
own Unicode strings into UTF-8 is very minimal.
4. Can't we make a ajax request to get the plain data which is sent by
> remote server { on copy event }. We can save the data in guacamole server
> when we receive data from remote server and on copy event fire an ajax
> request ).
>
No (see above-described issues with copy). Being able to modify local
clipboard data within the copy event would require blocking the main
thread, which cannot be done reliably.
> I had already done few change in the JavaScript code to make it work. It
> is *working in Chrome* only. Microsoft Edge hangs and IE ( issues while
> updating the local clipboard ).
>
I do not recommend making these changes. It is not possible to do what you
describe reliably.
If anyone has any suggestions, Please share in this thread.
>
>From my perspective, the best path forward is to use the clipboard APIs
which are on the track for standardization and have already been adopted by
the mainstream browsers:
https://www.w3.org/TR/clipboard-apis/
Guacamole already does this. As implementation of these APIs improves,
behavior of the clipboard within Guacamole will also improve. Currently,
IE10 and IE11 will prompt the user to grant clipboard access when these
APIs are used. If other browsers follow suit, displaying permissions
prompts for clipboard access similar to the prompts already displayed for
audio/video input, etc., then there will be no need to attempt these
workarounds.
Again, please beware that *we have tried all these clipboard-related
workarounds before*. Though they may seem inviting, they do not work well
in practice, and actually make the user experience more confusing.
- Mike
