Hi Aaron,
I'm not sure I understand you correctly. The purpose of this site is
to provide the user JS UI and the ability to choose which client
(java or flash) should be used as backend right? But this client
itself is not supposed to be used directly here as the GUI written
in HTML + JS does the whole work. If we want to provide user these
clients direct then we have separated pages for it (tcpbw100 and
tcpbw100-java). So what about hiding these controls on the
widget.html site so that only JS UI will be visible? Or am I missing
something and it should work different way?
Also for ensuring: by writing that it worked you mean JS UI or
running flash client located on the bottom of the site?
Kind regards
Sebastian
On 13.11.2014 15:43, Aaron Brown wrote:
Hey Sebastian,
Ah ok. I’ve got Flash Block on the browsers so the applet did
load, but because of how the page loads, wasn’t visible so I
didn’t realize I needed to click on it first. Once I clicked on
that, it worked. Given the prevelance of flash blockers, and the
odd nature of this HTML5 + Flash combo, is there a better way
that we can better locate the actual Applet on the page itself
so that, and put some text in, letting folks know they may need
to click on the hidden flash applet first?
Cheers,
Aaron
On Nov 13, 2014, at 9:36 AM, Sebastian Kostuch <>
wrote:
Hi Aaron,
as Pawel mentioned there is currently problem with calling
applet functions from JS as from
java 7u45 update there are more security restrictions to
applets. You can read more about it
here.
Basically now it is necessary to add
Caller-Allowable-Codebase line to manifest file (which I
have already commited) and jar file must be signed by a
trusted CA.
When it comes to issues you have mentioned, is there also
problem with calling start directly from applet or flash
embedded on the same site where JS UI is? Are there any
errors?
Kind regards
Sebastian
On 13.11.2014 15:20, Aaron
Brown wrote:
Hey Pawel,
On Nov 13, 2014, at 9:11 AM, Paweł Gesek <>
wrote:
Aaron,
I've taken a look and talked with Sebastian
about this. The new page uses the applet by
default if your browser supports java, however
there is some sort of problem with the
_javascript_-applet communication, making the
gauges do nothing if you are using the applet.
Have you tried pressing the flash button below
in order to switch the client to flash?
It doesn’t matter what I use, both bomb out, and
don’t (as far as i can tell anyway) perform any
tests.
One question
regarding your changes, any reason to change
nobase_ndt_DATA to ndt_DATA in
HTML5-frontend/Makefile.am? Without the nobase
modifier HTML5-frontend/images and
HTML5-frontend/fonts get installed in /usr/ndt
without the fonts or images subdirectory,
which leads to missing resources on the
webpage.
The install had failed as is, and as part of my
monkeying, i’d removed it, and then forgot about it
when it didn’t fix the issue. It’s been restored in
my latest commit.
Cheers,
Aaron
Regards,
Paweł
On 11/12/2014 05:04 PM, Aaron Brown wrote:
Hey Pawel,
I couldn’t get the RPM to build using
mock, so I committed some changes so I could
build the RPM. However, after installing the
RPM, going to the web and hitting start, it
doesn’t seem to do anything for me.
Navigating to the flash client directly,
however, does seem to work.
Cheers,
Aaron
On Nov 12, 2014, at 8:53 AM, Paweł
Gesek <>
wrote:
I've
added the flashpolicyd script with
some small modifications to the NDT
repository. It is started by the ndt
daemon and can be disabled in the
sysconfig file in the same way as
the fakewww daemon.
I believe I am finished with the RPM
work, the changes are on the branch
"Issues162". Please review and let
me know if I missed something or you
feel something needs to be changed.
Regards,
Paweł
On 11/07/2014 04:14 PM, Paweł Gesek
wrote:
Great,
I'll look at packaging that script
with NDT. I assume we should
bundle it with the ndt-server rpm.
I'm also thinking that we can
handle this in a similar fashion
we do with fakewww - the ndt
daemon will handle starting and
stopping of that script. Is that
okay?
It's possible I missed fakewww,
I'll take a look and make sure its
consistent with httpd. As for
widget.html it allows switching
between the applet and flash
client.
Regards,
Paweł
On 11/07/2014 03:42 PM, Aaron
Brown wrote:
That script looks reasonable. As
long as it can be reasonably be
packaged with NDT, I’d be fine
with it.
Cheers,
Aaron
On Nov 7, 2014, at 8:15
AM, Jordan McCarthy <>
wrote:
-----BEGIN PGP SIGNED
MESSAGE-----
Hash: SHA512
For what it's worth, the
M-Lab platform uses the
second approach,
embodied in this file:
https://github.com/m-lab-tools/ndt-support/blob/master/flashpolicyd.py
If this code looks
reasonable to you all,
please feel free to use
it!
Jordan
Jordan McCarthy
Open Technology Institute
| New America Foundation
Public Key: 0xC08D8042 |
4A61 3D39 4125 127D 65EA
DDC2 BFBD A2E9 C08D 8042
On 11/07/2014 04:46 AM,
Paweł Gesek wrote:
Hello
everyone,
I have been looking at
updating the NDT RPM so
that the flash
client there works out
of the box(Issue162
<https://code.google.com/p/ndt/issues/detail?id=162>).
I've
committed changes to the
branch
Issue162(https://code.google.com/p/ndt/source/detail?r=1144),
which
make the HTML5-frontend
install with NDT and
changed the index page
in the apache
configuration to the new
widget.html.
As far as running the
Flash client out of the
box goes, the NDT
server has to expose the
crossdomain.xml file,
which is required
for the Flash client to
allow opening sockets to
the server.
Unfortunately the socket
policy does not go
through HTTP, but a
simple proprietary
protocol that uses the
TCP port 843. I am
wondering for the best
way to handle this in
the NDT rpm. We can
possibly add a
requirement for a
package like
https://code.google.com/p/flashpolicyd/
and use that to serve
the
file. We could also
consider bundling some
sort of a simple server
script(like this
https://github.com/xantus/mojo-websocket-examples/blob/master/script/flash-policy-server)
that would serve the
policy file. Do you
preferences on how to
resolve this?
Regards, Paweł
-----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.11
(GNU/Linux)
iQEcBAEBCgAGBQJUXMYFAAoJEL+9ounAjYBCzD4IAKkSGdqsimCHWyD0ZdQcdD7W
wXH7emXDbO7z2jSojcNSKGqQe6wLPWFsQPN5PPwQqYdTs8bigxaKb7wGNC3qNBD5
B2FJ1Ohle10Et2NW20m+TCoORSQiYjpGCI+UenhbiV5B57BBE3t8cRgpHtxOiHjc
c2zxelECxdHq5eZ7f1JvAxWqdhUJZNVbWr7uIVGggcwe/b5Vg0yq9cqzIaVEX/bL
t9PEeYdzmmNq8ctjfKzgNEjNQo3Sp9O29nFB70KR9YNXvf0bOupJ76msI+FbRWaV
iOhgbCzfyHuHcTxQuHfxtUm5mf03cJ0QDWP5qFgTJPQSFrPYB5h4uENuMcgxKRw=
=bfO0
-----END PGP
SIGNATURE-----
|
