NDT-DEV email list created

[Will Hawkins <>]

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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>
>