<div dir="ltr"><div><div>Hello again!<br><br></div>While I know the format used for exchanging data, I would like to know what the server part will run on. As I understand it in autobuild, data is sent in a zipped file through ssh, and displayed using a CGI module in Perl. Now, if we want to allow users people to upload data, ssh is probably not a good option, and I would rather with a POST receiver on the server instead. This can be done quite easily in Python. The data can then be in a text file format, or even zipped, so we can upload many results at once. We could add HTTP authentication if you don't think everyone should be allowed to publish results before registering. <br>
<br></div><div>So, I would make the server part a single CGI module in python, probably just using the 'cgi' package and a template engine rather than a full web framework. Relying on POST commands instead of ssh upload would probably make listening for changes easier, but I would like to know if you want proper authentication or not. <br>
<br></div><div>Regards,<br>Miha<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/12 Miha Čančula <span dir="ltr"><<a href="mailto:miha@noughmad.eu" target="_blank">miha@noughmad.eu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">2013/9/11 Christian Engwer <span dir="ltr"><<a href="mailto:christian.engwer@uni-muenster.de" target="_blank">christian.engwer@uni-muenster.de</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Miha,<br>
<br>
I had a look at your latest code and it looks nice.<br>
<br>
I have a small questions:<br>
  what is the m4/add-test.m4 supposed to do?<br></blockquote></div><div>Thank you. This file is a remnant of a different approach I tried, and is not used anymore. I will remove it. <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br>
> Right now I'm writing an overview report of a single test run, to see which<br>
> tests run the longest, but from this on I'm not exactly sure what to do.<br>
> I've deviated considerably from the initial plan, but IMO it's best to<br>
> stick with it, and add upload functionality. If you have other priorities,<br>
> please tell me.<br>
<br>
</div>Yes, I think this is the currently. I think we have reached the major<br>
milestone. We have a usable performance testing environment. THe next<br>
major step will be support for the remote infrastructure.<br>
<br>
I suggest to add an option to dump the collected results to txt file<br>
instead of the database, this way it will be possible to transfer the<br>
data using the existing infrastructure. Regarding the format search<br>
through my older mails and/or have a look at the dune-autobuild<br>
output. If you keep some things flexible, e.g. the exact location of<br>
the log files, it shouldn't be too difficult to adjust this to other<br>
systems aswell.<br></blockquote></div><div>Yes, I will do that. <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ciao<br>
<span><font color="#888888">Christian<br>
</font></span><br>
PS: I'm not up-to-date... will you manage to come to the DUNE meeting?<br></blockquote></div><div>No, unfortunately not. I received my final confirmation this week that I'll be giving a talk at a conference on microelecronics at the exact same time (25-27 September). <br>

</div></div><br></div></div>
</blockquote></div><br></div>