NDT-DEV email list created

[Aaron Brown <>]

Hey Will,

done and done

Cheers,
Aaron

On Jun 27, 2014, at 3:58 PM, Will Hawkins 
<>
 wrote:

> Feel free to go ahead! You have the power to commit directly to trunk so
> that'll just be easier :-)
> 
> On 06/27/2014 02:41 PM, Aaron Brown wrote:
>> Hey Will,
>> 
>> Should I commit my version of the patch, or did you want to?
>> 
>> Cheers,
>> Aaron
>> 
>> On Jun 27, 2014, at 1:14 PM, Will Hawkins 
>> <>
>>  wrote:
>> 
>>> Thanks Aaron!
>>> 
>>> On 06/27/2014 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;
>>>>> +      }
>>>> 
>>> 
>>> I think that I was trying to be too clever here. I suppose that the
>>> "assignments have values" idiom does not apply to ActionScript :-)
>>> 
>>> Will
>>> 
>>>> 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
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>>