NDT-DEV email list created

[Aaron Brown <>]

Hey Will,

Yeah. I find it baffling they didn’t wrap that in an HTTP POST. It’ll just 
make packaging an RPM for this a bit more awkward since it’ll need to include 
the silly socket server instead of some apache config file. Sigh...

Cheers,
Aaron

On Jun 27, 2014, at 1:11 PM, Will Hawkins 
<>
 wrote:

> I think that your googling is probably correct. The files are served
> over that funky port (843) and they use a "special" protocol. To request
> the policy file, the client sends
> 
> <policy-file-request/>NULL
> 
> and then gets back the policy which governs subsequent connections.
> 
> Based on
> http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7c60.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7c63,
> it appears that socket policy files can no longer be accessed via
> http(s). However, based on this
> (http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/Security.html#loadPolicyFile%28%29),
> it looks like changing the default port number is possible:
> 
> Security.loadPolicyFile("xmlsocket://foo.com:414");
> 
> That probably doesn't help us much, but I thought I'd throw it out there!
> 
> Will
> 
> On 06/27/2014 11:00 AM, Aaron Brown wrote:
>> Hey Will,
>> 
>> I’m guessing the answer is no from my searching, but I was wondering if 
>> you knew if it was possible to server the socket policy files via a 
>> webserver instead of the strange socket policy server.
>> 
>> Cheers,
>> Aaron
>> 
>> On Jun 27, 2014, at 10:02 AM, Aaron Brown 
>> <>
>>  wrote:
>> 
>>> Hey Will,
>>> 
>>> Seems to work for me. The compiler spit out a warning about assignments 
>>> in if statements, so I modified the if statement to look like:
>>> 
>>>> +      var selfUrl:String = URLUtil.getServerName(this.loaderInfo.url);
>>>> +      if (selfUrl) {
>>>> +        server_hostname = selfUrl;
>>>> +      }
>>> 
>>> Cheers,
>>> Aaron
>>> 
>>> On Jun 26, 2014, at 11:04 PM, Will Hawkins 
>>> <>
>>>  wrote:
>>> 
>>>> How about this?
>>>> 
>>>> Index: src/Main.as
>>>> ===================================================================
>>>> --- src/Main.as    (revision 1112)
>>>> +++ src/Main.as    (working copy)
>>>> @@ -16,6 +16,7 @@
>>>> import flash.display.Sprite;
>>>> import flash.events.Event;
>>>> import mx.resources.ResourceBundle;
>>>> +  import mx.utils.URLUtil;
>>>> /**
>>>>  * @author Anant Subramanian
>>>>  */
>>>> @@ -45,6 +46,11 @@
>>>>   private function init(e:Event = null):void {
>>>>     removeEventListener(Event.ADDED_TO_STAGE, init);
>>>> 
>>>> +      var selfUrl:String = null;
>>>> +      if (selfUrl = URLUtil.getServerName(this.loaderInfo.url)) {
>>>> +        server_hostname = selfUrl;
>>>> +      }
>>>> +
>>>>     // Set the properties of the SWF from HTML tags.
>>>>     NDTUtils.initializeFromHTML(this.root.loaderInfo.parameters);
>>>> 
>>>> 
>>>> Will
>>>> 
>>>> On 06/26/2014 01:50 PM, Will Hawkins wrote:
>>>>> 
>>>>> 
>>>>> On 06/26/2014 09:13 AM, Aaron Brown wrote:
>>>>>> Hey Will,
>>>>>> 
>>>>>> On Jun 25, 2014, at 9:51 PM, Will Hawkins 
>>>>>> <>
>>>>>>  wrote:
>>>>>> 
>>>>>>> I am happy to create a branch for this, but I think that might be
>>>>>>> overkill. Here's what I added
>>>>>>> 
>>>>>>> Index: src/Main.as
>>>>>>> ===================================================================
>>>>>>> --- src/Main.as (revision 1112)
>>>>>>> +++ src/Main.as (working copy)
>>>>>>> @@ -45,6 +45,14 @@
>>>>>>>  private function init(e:Event = null):void {
>>>>>>>    removeEventListener(Event.ADDED_TO_STAGE, init);
>>>>>>> 
>>>>>>> +      var selfUrl:String = this.loaderInfo.url;
>>>>>>> +      if (selfUrl.indexOf("http://";, 0) == 0) {
>>>>>>> +        selfUrl = selfUrl.replace("http://";, "");
>>>>>>> +        selfUrl = selfUrl.replace(/:[0-9]+/, "");
>>>>>>> +        selfUrl = selfUrl.replace(/\/.+$/, "");
>>>>>>> +        server_hostname = selfUrl;
>>>>>>> +      }
>>>>>>> +
>>>>>>>    // Set the properties of the SWF from HTML tags.
>>>>>>>    NDTUtils.initializeFromHTML(this.root.loaderInfo.parameters);
>>>>>> 
>>>>>> Looking at the parsing there, it will definitely fail on IPv6 
>>>>>> addresses. It looks like actionscript has a URL library 
>>>>>> (http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/utils/URLUtil.html)
>>>>>>  that would probably work for returning the address to test against.
>>>>>> 
>>>>> 
>>>>> Oh, I get it. You don't think that two quickly-hacked-together regexes
>>>>> covers all possible cases? You'd like me to use a library?
>>>>> 
>>>>> NO. :-)
>>>>> 
>>>>> Just kidding, of course. I was actually hoping that loaderInfo.url
>>>>> returned some type of object that I could easy inquire about the
>>>>> hostname. But, it seems like the URL library is the way to go. Standby
>>>>> for another rev.
>>>>> 
>>>>> Will
>>>>> 
>>>>> 
>>>>>>> This will make it default to test against an NDT server running on the
>>>>>>> same host from which the swf was loaded. This does not preclude the 
>>>>>>> user
>>>>>>> from overriding that value with their JS callback.
>>>>>>> 
>>>>>>> The other, perhaps easier, option is to do something similar in the JS
>>>>>>> that hosts the Flash applet. JS would parse window.location and then
>>>>>>> return that value in the getNDTServer() callback.
>>>>>>> 
>>>>>>> Let me know which route you prefer!
>>>>>> 
>>>>>> My general preference would be to encode that default into the Flash 
>>>>>> client to make it as simple as possible to embed the client in 
>>>>>> webpages.
>>>>>> 
>>>>>> Cheers,
>>>>>> Aaron
>>>>>> 
>>>>>> 
>>>>>>> Will
>>>>>>> 
>>>>>>> On 06/25/2014 02:22 PM, Aaron Brown wrote:
>>>>>>>> Hey Will,
>>>>>>>> 
>>>>>>>> On Jun 25, 2014, at 1:59 PM, Will Hawkins 
>>>>>>>> <>
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>>> Hey Aaron!
>>>>>>>>> 
>>>>>>>>> I am working on this -- I promise :-)
>>>>>>>> 
>>>>>>>> Excellent, no rush :)
>>>>>>>> 
>>>>>>>>> Just to get some context, are you assuming that we would include an 
>>>>>>>>> HTML
>>>>>>>>> wrapper for the Flash client and invoke the wrapped version to 
>>>>>>>>> actually
>>>>>>>>> do the self testing? I'm just trying to figure out which of the
>>>>>>>>> Actionscript facilities I'll have access to in order to resolve this
>>>>>>>>> dilemma.
>>>>>>>> 
>>>>>>>> That’s what I’m thinking. Similar to how the java applet works (e.g. 
>>>>>>>> http://desk146.internet2.edu:7123/), you’d go to a webpage and the 
>>>>>>>> flash client would be embedded in the page. You could then just hit 
>>>>>>>> “start”, and it’d do a test from your machine to the server that 
>>>>>>>> served it.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Aaron
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Will
>>>>>>>>> 
>>>>>>>>> On 06/24/2014 10:13 AM, Aaron Brown wrote:
>>>>>>>>>> Hey Will,
>>>>>>>>>> 
>>>>>>>>>> I’ve got the RPM working with the existing fakewww/Applet.
>>>>>>>>>> 
>>>>>>>>>> I’d like to include the flash client in the RPM if possible 
>>>>>>>>>> (otherwise, there’s not much benefit to the average RPM install 
>>>>>>>>>> for the new release). Unfortunately, it doesn’t look like there’s 
>>>>>>>>>> a good way to zero-configuration install (i.e. have it by default 
>>>>>>>>>> test back to the server it was served from) without using 
>>>>>>>>>> something like PHP (which would require swapping over to using 
>>>>>>>>>> Apache to serve the clients). Would it be possible to include a 
>>>>>>>>>> setting for the flash client to say “the server to use is the 
>>>>>>>>>> address of the server you downloaded the SWF from”?
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Aaron
>>>>>>>>>> 
>>>>>>>>>> On Jun 20, 2014, at 8:02 PM, Will Hawkins 
>>>>>>>>>> <>
>>>>>>>>>>  wrote:
>>>>>>>>>> 
>>>>>>>>>>> Please let me know if/how I can help preparing the repo for RPM
>>>>>>>>>>> creation. I'm happy to give it a try on my own, but if there is
>>>>>>>>>>> expertise elsewhere (Aaron or Sebastian), then I am happy to take 
>>>>>>>>>>> a back
>>>>>>>>>>> seat.
>>>>>>>>>>> 
>>>>>>>>>>> As for testers, we (MLab) can definitely find a few places to 
>>>>>>>>>>> test. I
>>>>>>>>>>> know that we've been running trunk versions of the server on 
>>>>>>>>>>> several
>>>>>>>>>>> test nodes for a while and haven't had any problems (besides the 
>>>>>>>>>>> ones
>>>>>>>>>>> that I've submitted patches for).
>>>>>>>>>>> 
>>>>>>>>>>> Will
>>>>>>>>>>> 
>>>>>>>>>>> On 06/20/2014 09:54 AM, Aaron Brown wrote:
>>>>>>>>>>>> Hey Sebastian,
>>>>>>>>>>>> 
>>>>>>>>>>>> I’m untagging the release since I can guarantee we’ll need to 
>>>>>>>>>>>> make changes to the codebase for the NDT RPMs, and those are a 
>>>>>>>>>>>> requirement for outside testing since a very small percentage of 
>>>>>>>>>>>> NDT servers out there are compiled from source. I’ll commit some 
>>>>>>>>>>>> of the RPM bits, and then if you could go through, and make sure 
>>>>>>>>>>>> that it gets updated as needed for the changes (new web UI, 
>>>>>>>>>>>> etc), that’d be good. The goal of the NDT RPMs is that the 
>>>>>>>>>>>> administrators can do “yum install ndt-server”, start NDT and it 
>>>>>>>>>>>> just works. They don’t have to do any hand configuration to get 
>>>>>>>>>>>> an NDT server up-and-running.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Aaron
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jun 20, 2014, at 5:15 AM, Sebastian Kostuch 
>>>>>>>>>>>> <>
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>> Will, I have merged your last fixes into trunk so they will be 
>>>>>>>>>>>>> contained within
>>>>>>>>>>>>> new release :).
>>>>>>>>>>>>> Aaron, keeping in mind what you have said I have changed 
>>>>>>>>>>>>> version numbers
>>>>>>>>>>>>> to be release candidate and tagged this. Such tagged version is 
>>>>>>>>>>>>> now ready
>>>>>>>>>>>>> for being tested by outside folks. I hope that test stage will 
>>>>>>>>>>>>> perform smoothly
>>>>>>>>>>>>> and we would release new NDT version ASAP!
>>>>>>>>>>>>> Also I have updated wiki pages to match new protocol changes.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Sebastian Kostuch
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 18.06.2014 23:00, Will Hawkins wrote:
>>>>>>>>>>>>>> Aaron,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks for the information! We (M-Lab) are especially 
>>>>>>>>>>>>>> interested in
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> a) having the code "checked" to make sure that the 
>>>>>>>>>>>>>> measurements are
>>>>>>>>>>>>>> still valid
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> b) having a release to deploy on the platform.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Having said that, what is the best way to prepare a release 
>>>>>>>>>>>>>> candidate to
>>>>>>>>>>>>>> start the process rolling? Are you able to help verify the 
>>>>>>>>>>>>>> measurements
>>>>>>>>>>>>>> made with the new version of the tool? Will you be able to 
>>>>>>>>>>>>>> help,
>>>>>>>>>>>>>> generally, with the release process (since, I mean, you're 
>>>>>>>>>>>>>> awesome!)?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks again for your email!
>>>>>>>>>>>>>> Will
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 06/18/2014 04:46 PM, Aaron Brown wrote:
>>>>>>>>>>>>>>> Hi Sebastian,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> To do a full release, NDT will need to go through a release 
>>>>>>>>>>>>>>> candidate process to ensure that outside folks have a chance 
>>>>>>>>>>>>>>> to test it before something gets labeled as “released”. 
>>>>>>>>>>>>>>> Beyond that, NDT will need verified to make sure that 
>>>>>>>>>>>>>>> something didn’t break with existing clients (important since 
>>>>>>>>>>>>>>> this is a less common use-case). The upgrade process needs to 
>>>>>>>>>>>>>>> be verified as well to make sure that it doesn’t break an 
>>>>>>>>>>>>>>> existing installation when someone goes to upgrade.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> As part of the upgrade procedure above, the RPMs will need 
>>>>>>>>>>>>>>> updated with any changes in the codebase since that’s the 
>>>>>>>>>>>>>>> primary method folks use to install NDT (the vast majority of 
>>>>>>>>>>>>>>> NDT installations in the wild are installed as part of the 
>>>>>>>>>>>>>>> perfSONAR Performance Toolkit). This procedure will need 
>>>>>>>>>>>>>>> tested to make sure that both new installs, and existing 
>>>>>>>>>>>>>>> installs work as expected.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Once there’s a final release, the NDT RPMs will get added to 
>>>>>>>>>>>>>>> the Internet2 RPM repository (where the Toolkit users get 
>>>>>>>>>>>>>>> their RPMs from), and the source tarball will be added to the 
>>>>>>>>>>>>>>> Internet2 site at software.internet2.edu). Presumably, this 
>>>>>>>>>>>>>>> link could be used as canonical for NDT since any linked 
>>>>>>>>>>>>>>> location is arbitrary from the end user perspective.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Aaron
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jun 18, 2014, at 6:04 AM, Sebastian Kostuch 
>>>>>>>>>>>>>>> <>
>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi again,
>>>>>>>>>>>>>>>> new NDT version is coming soon, however there are last 
>>>>>>>>>>>>>>>> changes to be performed
>>>>>>>>>>>>>>>> before this. I have merged all changes to release into 
>>>>>>>>>>>>>>>> trunk, tested and fixed individual
>>>>>>>>>>>>>>>> small bugs. Next step will be to update our wiki pages to 
>>>>>>>>>>>>>>>> match new version which I will
>>>>>>>>>>>>>>>> be working on in nearest time.
>>>>>>>>>>>>>>>> However I wanted to ask two last questions to you:
>>>>>>>>>>>>>>>> 1. So far new release package has been published in 
>>>>>>>>>>>>>>>> "downloads" section of google code
>>>>>>>>>>>>>>>> project but recently Google has disabled this option. 
>>>>>>>>>>>>>>>> Therefore should we place such archive
>>>>>>>>>>>>>>>> in some external source like Google drive where users could 
>>>>>>>>>>>>>>>> directly download this (and update
>>>>>>>>>>>>>>>> wiki with such link)? Or maybe just publish link to release 
>>>>>>>>>>>>>>>> tagged revision?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 2. Also what about updating NDT links/software on another 
>>>>>>>>>>>>>>>> sites? I know that it will be performed
>>>>>>>>>>>>>>>> on M-lab but what about Internet2 website?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 18.06.2014 09:06, Sebastian Kostuch wrote:
>>>>>>>>>>>>>>>>> Hi Will
>>>>>>>>>>>>>>>>> indeed these changes results in higher speeds (I was able 
>>>>>>>>>>>>>>>>> to get ~760 mbps
>>>>>>>>>>>>>>>>> which is quite similar to yours). Also I have checked flash 
>>>>>>>>>>>>>>>>> client as background
>>>>>>>>>>>>>>>>> for new JS UI and both speeds are being updated correctly 
>>>>>>>>>>>>>>>>> in real-time. This is
>>>>>>>>>>>>>>>>> really great work! Thanks for this. I have merged these 
>>>>>>>>>>>>>>>>> changes into trunk so
>>>>>>>>>>>>>>>>> they would be also present in new release.
>>>>>>>>>>>>>>>>> Also as you probably have noticed I have fixed compilation 
>>>>>>>>>>>>>>>>> error when using
>>>>>>>>>>>>>>>>> web100 so I closed appropriated issue related to this.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 17.06.2014 22:52, Will Hawkins wrote:
>>>>>>>>>>>>>>>>>> Hello Sebastian and Aaron (and MLab'ers CC'd),
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> We found a way to juice the Flash client and achieve the 
>>>>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>>>>> necessary to accurately measure high-speed network 
>>>>>>>>>>>>>>>>>> connections.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> The change is in r1082.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> The solution was counterintuitive (at least for me). 
>>>>>>>>>>>>>>>>>> Instead of
>>>>>>>>>>>>>>>>>> attempting to read data from the socket as quickly as 
>>>>>>>>>>>>>>>>>> possible, the
>>>>>>>>>>>>>>>>>> TestS2C class just gets out of the way for the duration of 
>>>>>>>>>>>>>>>>>> the test. It
>>>>>>>>>>>>>>>>>> registers only for the "socket close" event. The runtime 
>>>>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>>>>> necessary speed to keep up with the network.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> The only problem with this method is keeping the user 
>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>> up-to-date on progress throughout the test. Sebastian, 
>>>>>>>>>>>>>>>>>> this is where I
>>>>>>>>>>>>>>>>>> need you to double check. I believe that the code in r1082 
>>>>>>>>>>>>>>>>>> properly
>>>>>>>>>>>>>>>>>> updates _s2cByteCount in the appropriate spot for those 
>>>>>>>>>>>>>>>>>> real-time
>>>>>>>>>>>>>>>>>> updates (specifically onSpeedUpdate). But, please double 
>>>>>>>>>>>>>>>>>> check!
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> We were able to measure a connection at ~ 775 mbps using 
>>>>>>>>>>>>>>>>>> the Flash
>>>>>>>>>>>>>>>>>> client, but it would be great to have as many people test 
>>>>>>>>>>>>>>>>>> this as
>>>>>>>>>>>>>>>>>> possible. To do so, you can use a pre-compiled version at
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> http://files.opentechinstitute.org/~hawkinsw/flash/test.html
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On a separate, but related note, please also review r1083 
>>>>>>>>>>>>>>>>>> for inclusion
>>>>>>>>>>>>>>>>>> in the NDT release. This change allows the client to 
>>>>>>>>>>>>>>>>>> re-query JS for the
>>>>>>>>>>>>>>>>>> test's hostname just before launching a test. This gives 
>>>>>>>>>>>>>>>>>> the wrapper
>>>>>>>>>>>>>>>>>> page the opportunity to do a AJAX query to determine the 
>>>>>>>>>>>>>>>>>> test's
>>>>>>>>>>>>>>>>>> hostname. This is important for MLab because we do dynamic 
>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>> selection using a web-based API.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I am eager to hear whether you have success with these 
>>>>>>>>>>>>>>>>>> changes or not. I
>>>>>>>>>>>>>>>>>> hope you do!
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Will
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 06/17/2014 10:53 AM, Will Hawkins wrote:
>>>>>>>>>>>>>>>>>>> Just FYI: I believe that we have happened on to an actual 
>>>>>>>>>>>>>>>>>>> solution for
>>>>>>>>>>>>>>>>>>> the "limit" to the performance of the S2C test. I am 
>>>>>>>>>>>>>>>>>>> going to implement
>>>>>>>>>>>>>>>>>>> it today and do some testing.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> If possible, could we hold out on doing a release for a 
>>>>>>>>>>>>>>>>>>> little while
>>>>>>>>>>>>>>>>>>> pending this investigation?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Will
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 06/16/2014 01:50 AM, Sebastian Kostuch wrote:
>>>>>>>>>>>>>>>>>>>> Hi Will,
>>>>>>>>>>>>>>>>>>>> what you mentioned seems reasonable. Would it be 
>>>>>>>>>>>>>>>>>>>> possible to merge these
>>>>>>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>>>>>>> changes into trunk in nearest time so we could make new 
>>>>>>>>>>>>>>>>>>>> release for
>>>>>>>>>>>>>>>>>>>> example tomorrow
>>>>>>>>>>>>>>>>>>>> or the day after tomorrow?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 13.06.2014 17:36, Will Hawkins wrote:
>>>>>>>>>>>>>>>>>>>>> Sebastian,
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Thanks for sending this out! We (at MLab) are very 
>>>>>>>>>>>>>>>>>>>>> interested in
>>>>>>>>>>>>>>>>>>>>> deploying a new version of the code so this 'release' 
>>>>>>>>>>>>>>>>>>>>> looks like a
>>>>>>>>>>>>>>>>>>>>> good place to fit together! :-) In other words, we 
>>>>>>>>>>>>>>>>>>>>> (again, MLab) are
>>>>>>>>>>>>>>>>>>>>> definitely going to do what you said in 3!
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I am out of the office, but I wanted to quickly respond 
>>>>>>>>>>>>>>>>>>>>> to point 2.
>>>>>>>>>>>>>>>>>>>>> See below!
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Thanks again for driving this process forward!!
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Will
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 6/13/14, 4:47 AM, Sebastian Kostuch wrote:
>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>> NDT has been updated recently with some major changes 
>>>>>>>>>>>>>>>>>>>>>> (like
>>>>>>>>>>>>>>>>>>>>>> MSG_EXTENDED_LOGIN,
>>>>>>>>>>>>>>>>>>>>>> json support, new JS UI) so as I have mentioned in 
>>>>>>>>>>>>>>>>>>>>>> some earlier mail
>>>>>>>>>>>>>>>>>>>>>> that would be probably
>>>>>>>>>>>>>>>>>>>>>> good time to make new release. I have few questions 
>>>>>>>>>>>>>>>>>>>>>> related to this:
>>>>>>>>>>>>>>>>>>>>>> 1. New JS UI would fit well within this new release, 
>>>>>>>>>>>>>>>>>>>>>> however changes
>>>>>>>>>>>>>>>>>>>>>> related to this are still
>>>>>>>>>>>>>>>>>>>>>> on work branches and need review. Any feedback would 
>>>>>>>>>>>>>>>>>>>>>> be very
>>>>>>>>>>>>>>>>>>>>>> appreciated. These are
>>>>>>>>>>>>>>>>>>>>>> following issues: 129, 132, 133.
>>>>>>>>>>>>>>>>>>>>>> 2. Is Issue144 (URLLoader to flash) supposed to be 
>>>>>>>>>>>>>>>>>>>>>> contained also in
>>>>>>>>>>>>>>>>>>>>>> nearest release version?
>>>>>>>>>>>>>>>>>>>>>> If yes, then how does progress with work on this look 
>>>>>>>>>>>>>>>>>>>>>> like? If I recall
>>>>>>>>>>>>>>>>>>>>>> correctly then you, Will,
>>>>>>>>>>>>>>>>>>>>>> mentioned that they are well tested and thus almost 
>>>>>>>>>>>>>>>>>>>>>> ready, right?
>>>>>>>>>>>>>>>>>>>>> Some of these are still up for debate. I am going to 
>>>>>>>>>>>>>>>>>>>>> forward an email
>>>>>>>>>>>>>>>>>>>>> that I just sent to the MLab team with an update on the 
>>>>>>>>>>>>>>>>>>>>> conundrum
>>>>>>>>>>>>>>>>>>>>> around the HTTP test to give you a sense about why they 
>>>>>>>>>>>>>>>>>>>>> are up for
>>>>>>>>>>>>>>>>>>>>> debate.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> But, there are also changes in that branch that *need* 
>>>>>>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>>>>>>> incorporated into anything that gets released. For 
>>>>>>>>>>>>>>>>>>>>> instance, r1070.
>>>>>>>>>>>>>>>>>>>>> There are parts of r1064 that will have to be 
>>>>>>>>>>>>>>>>>>>>> integrated no matter
>>>>>>>>>>>>>>>>>>>>> what (any of the changes that have to do with splitting 
>>>>>>>>>>>>>>>>>>>>> start test and
>>>>>>>>>>>>>>>>>>>>> finalize test stages).
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Does that make sense?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 3. Along with new release on googlecode what do you 
>>>>>>>>>>>>>>>>>>>>>> think about pushing
>>>>>>>>>>>>>>>>>>>>>> these changes also
>>>>>>>>>>>>>>>>>>>>>> on M-Lab site? They bring many new features at all.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Looking forward to your answers and I hope that next 
>>>>>>>>>>>>>>>>>>>>>> week could be
>>>>>>>>>>>>>>>>>>>>>> celebrated with making
>>>>>>>>>>>>>>>>>>>>>> new release of NDT :).
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Kind regards
>>>>>>>>>>>>>>>>>>>>>> Sebastian Kostuch
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>> 
>>