NDT-DEV email list created

[Jakub Sławiński <>]

I agree with Aaron. If user can use Java client then it should be used
instead of the Flash one.


Regards,
  Jakub.

On 08/01/2014 04:56 PM, Aaron Brown wrote:
> Hey Sebastian,
> 
> That’s a tricky question. There are pros and cons with each:
> 
> Java: pro: it performs well on all platforms. con: people are disabling it 
> (though with the signing cert, some of these problems may go away)
> Flash: pro: pretty much everyone has it. con: it doesn’t perform well in 
> certain configurations.
> 
> I guess my preference would be Java due to the performance issues with 
> Flash. What do others think?
> 
> Cheers,
> Aaron
> 
> On Jul 31, 2014, at 3:38 AM, Sebastian Kostuch 
> <>
>  wrote:
> 
>> Hi Aaron,
>> thanks for your response. I will then make changes such as you proposed. 
>> Would it be better to use flash or java as default if users have both 
>> plugins installed on their system?
>>
>> Regards
>> Sebastian
>>
>> On 29.07.2014 16:42, Aaron Brown wrote:
>>> Hi Sebastian,
>>>
>>> The best case scenario would be to have the index page choose a sensible 
>>> default depending on whether flash or java are installed, and make it 
>>> easy for them to select it on the page if they want something different.
>>>
>>> Cheers,
>>> Aaron
>>>
>>> On Jul 25, 2014, at 1:42 AM, Sebastian Kostuch 
>>> <>
>>>  wrote:
>>>
>>>> Hi Aaron,
>>>> we will do our best to try to help you with mentioned task. When it 
>>>> comes to swapping "backend"
>>>> client then ATM there is script available ("set-active-client.sh) which 
>>>> allows to choose if user prefers
>>>> flash or java backend and properly updates HTML code. Is such a solution 
>>>> acceptable or should we
>>>> rather make it different way?
>>>>
>>>> Regards
>>>> Sebastian
>>>>
>>>> On 22.07.2014 19:22, Aaron Brown wrote:
>>>>> Hey Jakub,
>>>>>
>>>>> On Jul 22, 2014, at 10:52 AM, Jakub Sławiński 
>>>>> <>
>>>>>  wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think we will be able to help with the mentioned issues.
>>>>>>
>>>>>> Sebastian, can we already swap between flash and java backend on the
>>>>>> html level? Moreover, can we help with packaging up RPMs?
>>>>> If you could create RPMs for the flash components, that’d be great. 
>>>>> There’s a spec file in the trunk of the repository that you can add an 
>>>>> additional flash client component to.
>>>>>
>>>>> Cheers,
>>>>> Aaron
>>>>>
>>>>>> Regards,
>>>>>>  Jakub.
>>>>>>
>>>>>> On 07/21/2014 04:58 PM, Aaron Brown wrote:
>>>>>>> Hey Jakub,
>>>>>>>
>>>>>>> The big open part is getting the flash client packaged so that an 
>>>>>>> admin can do a “yum install [package]”, and have it just work. Among 
>>>>>>> other things, it’ll need to package up something to serve the default 
>>>>>>> flash socket xml stuff, and include a way, in the HTML, to swap 
>>>>>>> between the flash or java applet as the ‘backend’ of the javascript 
>>>>>>> so folks can run either. If you guys can work on packaging up RPMs, 
>>>>>>> that’d be great.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Aaron
>>>>>>>
>>>>>>> On Jul 21, 2014, at 10:48 AM, Jakub Sławiński 
>>>>>>> <>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> is there any progress regarding new NDT release? What has left to be
>>>>>>>> done and how we can help to make it happen?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Jakub.
>>>>>>>>
>>>>>>>> On 07/11/2014 03:15 AM, Richard Carlson wrote:
>>>>>>>>> Will;
>>>>>>>>>
>>>>>>>>> The approach you describe sounds reasonable.  I would be happy to 
>>>>>>>>> help
>>>>>>>>> test things out once you have them ready.
>>>>>>>>>
>>>>>>>>> Rich
>>>>>>>>>
>>>>>>>>> On 07/09/2014 08:53 PM, Will Hawkins wrote:
>>>>>>>>>> Mr. Carlson,
>>>>>>>>>>
>>>>>>>>>> Thank you for adding your insight on this. I certainly appreciate 
>>>>>>>>>> having
>>>>>>>>>> the chance to work with people as respected in the measurement 
>>>>>>>>>> world as
>>>>>>>>>> you and Matt.
>>>>>>>>>>
>>>>>>>>>> I agree that the goal should be not to tell the user that they are
>>>>>>>>>> incapable of choosing a good browser. In fact, I don't actually 
>>>>>>>>>> like
>>>>>>>>>> Chrome (shh, don't tell anyone!). I also agree that, in the case 
>>>>>>>>>> where
>>>>>>>>>> the user is running a "bad" browser/os combination, the 
>>>>>>>>>> measurements
>>>>>>>>>> made with this Flash client will be indicative of general 
>>>>>>>>>> performance on
>>>>>>>>>> their connection when running Flash applications (with the caveat 
>>>>>>>>>> that
>>>>>>>>>> HTTP-based network i/o is significantly faster than socket-based 
>>>>>>>>>> i/o
>>>>>>>>>> because it is implemented better by the runtime across platforms). 
>>>>>>>>>> As a
>>>>>>>>>> final note of agreement, I concur that NDT is more than just a 
>>>>>>>>>> "speed
>>>>>>>>>> test".
>>>>>>>>>>
>>>>>>>>>> The way that we are going to actually implement this is with a 
>>>>>>>>>> series of
>>>>>>>>>> configurable knobs. The person embedding the Flash client in their 
>>>>>>>>>> HTML
>>>>>>>>>> will have the option to treat an incompatible browser/os 
>>>>>>>>>> combination as
>>>>>>>>>> an error or a warning. They deployer will get to handle that 
>>>>>>>>>> condition
>>>>>>>>>> in a callback and display an appropriate message (so that they 
>>>>>>>>>> could say
>>>>>>>>>> something in "big bold letters", which I liked!).
>>>>>>>>>>
>>>>>>>>>> If that type of scenario is acceptable to you, the decision is more
>>>>>>>>>> about the appropriate default (error or warning). We are close to
>>>>>>>>>> finishing up an implementation. Would you be willing to review 
>>>>>>>>>> that when
>>>>>>>>>> it's ready and see if it meets your expectations?
>>>>>>>>>>
>>>>>>>>>> Thanks again for adding your thoughts! I was hoping that you'd 
>>>>>>>>>> weigh in.
>>>>>>>>>> We have Matt M on a separate thread adding his thoughts as well so 
>>>>>>>>>> I am
>>>>>>>>>> confident that we will come to a solid resolution.
>>>>>>>>>>
>>>>>>>>>> Will
>>>>>>>>>>
>>>>>>>>>> On 07/09/2014 08:40 PM, Richard Carlson wrote:
>>>>>>>>>>> Sebastian/Will;
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure I agree with this idea.  While I agree that letting 
>>>>>>>>>>> the
>>>>>>>>>>> user know that the test results are bad due to the Flash runtime
>>>>>>>>>>> problem, I'm not at all convinced that the proper response is to 
>>>>>>>>>>> say
>>>>>>>>>>> 'use Chrome'.  It just seems a bit strong to me, like you are 
>>>>>>>>>>> saying the
>>>>>>>>>>> user is too stupid to run a good browser.
>>>>>>>>>>>
>>>>>>>>>>> I'd prefer to let the test run and put in big bold letters across 
>>>>>>>>>>> the
>>>>>>>>>>> results page or in some other manner indicate that the limiting 
>>>>>>>>>>> factor
>>>>>>>>>>> is the client's flash runtime.  That way the user is being 
>>>>>>>>>>> informed and
>>>>>>>>>>> the logged test results can also contain the same notation so 
>>>>>>>>>>> they can
>>>>>>>>>>> be discarded if necessary.
>>>>>>>>>>>
>>>>>>>>>>> After all, they will get that performance when running other 
>>>>>>>>>>> flash apps,
>>>>>>>>>>> so it would be good for them to know what the limits are.
>>>>>>>>>>>
>>>>>>>>>>> The whole purpose of the NDT system is to provide advanced 
>>>>>>>>>>> diagnostic
>>>>>>>>>>> messages, not just run speed tests.  Showing the user that the 
>>>>>>>>>>> test
>>>>>>>>>>> results are limited and explaining why would be much better than 
>>>>>>>>>>> telling
>>>>>>>>>>> them to 'trust me and replace your browser's flash runtime'.
>>>>>>>>>>>
>>>>>>>>>>> So for me, the real question is can you make a simple and 
>>>>>>>>>>> intuitive
>>>>>>>>>>> image or text that clearly shows that the problem is the flash 
>>>>>>>>>>> runtime
>>>>>>>>>>> and not the NDT service.
>>>>>>>>>>>
>>>>>>>>>>> Rich
>>>>>>>>>>>
>>>>>>>>>>> On 07/08/2014 03:09 AM, Sebastian Kostuch wrote:
>>>>>>>>>>>> Hi Will,
>>>>>>>>>>>> IMHO it would be good to disable possibility of running test when
>>>>>>>>>>>> we detect that flash client is being run from within not 
>>>>>>>>>>>> supported
>>>>>>>>>>>> platform. With this there won't be faked results noted on server
>>>>>>>>>>>> side's statistics.
>>>>>>>>>>>> Also looking forward to any further information
>>>>>>>>>>>> regarding new release :).
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>
>>>>>>>>>>>> On 03.07.2014 02:40, Will Hawkins wrote:
>>>>>>>>>>>>> Sebastian and Aaron (and everyone, really),
>>>>>>>>>>>>>
>>>>>>>>>>>>> We at MLab are in the final throes of getting our platform ready
>>>>>>>>>>>>> for the
>>>>>>>>>>>>> Flash client. In so doing, we've gotten deep into the weeds on 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> performance/measurement implications of the Flash runtime.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wanted to present you with our findings and get your input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On all platforms (Windows, Mac, Linux), running the Flash 
>>>>>>>>>>>>> client in
>>>>>>>>>>>>> Google Chrome works a-ok. On Windows, running the Flash client 
>>>>>>>>>>>>> in all
>>>>>>>>>>>>> other browsers work great too. On Linux and Mac, however, that 
>>>>>>>>>>>>> is not
>>>>>>>>>>>>> the case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mac and Linux where the user runs the NDT Flash client under
>>>>>>>>>>>>> Adobe's
>>>>>>>>>>>>> runtime (i.e., browsers other than Chrome [even Chromium does 
>>>>>>>>>>>>> not
>>>>>>>>>>>>> work]), there is not enough network i/o fidelity to produce
>>>>>>>>>>>>> measurements
>>>>>>>>>>>>> for connections with > ~ 50mbps throughput (on the s2c side).
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words, Google's independent implementation of the Flash
>>>>>>>>>>>>> runtime
>>>>>>>>>>>>> performs well enough on all platforms, but Adobe's 
>>>>>>>>>>>>> implementation
>>>>>>>>>>>>> performs well enough only on Windows.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because MLab collects lots of data, we don't want our results 
>>>>>>>>>>>>> to be
>>>>>>>>>>>>> spoiled by tests whose results are artificially limited. We are
>>>>>>>>>>>>> attempting to work out a way to "encourage" users to run the 
>>>>>>>>>>>>> test
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> environment where we will get the most accurate results. To do 
>>>>>>>>>>>>> so,
>>>>>>>>>>>>> we've
>>>>>>>>>>>>> settled on the following plan:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1.  When the flash client detects that it is being run within a
>>>>>>>>>>>>> non-optimal environment, display the following:  
>>>>>>>>>>>>> "Unfortunately, this
>>>>>>>>>>>>> test cannot run within your current browser environment.  
>>>>>>>>>>>>> Please run
>>>>>>>>>>>>> the test from within Google Chrome, or download M-Lab's Firefox
>>>>>>>>>>>>> Extension."
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.  Disallow the flash client from running on any platform that
>>>>>>>>>>>>> identifies itself as something other than Windows / Chrome.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do people think about this plan? Reasonable?
>>>>>>>>>>>>>
>>>>>>>>>>>>> As always, it's great working with everyone in NDT land. I look
>>>>>>>>>>>>> forward
>>>>>>>>>>>>> to continuing the work :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Will
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 06/18/2014 03:06 AM, 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
>>>>>>>>>>>>>>>>>>>
>>
>