[Dune-devel] [GSoC] Keep documentation up to date

Miha Čančula miha at noughmad.eu
Thu Sep 12 10:19:15 CEST 2013


Hello again!

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.

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.

Regards,
Miha


2013/9/12 Miha Čančula <miha at noughmad.eu>

> 2013/9/11 Christian Engwer <christian.engwer at uni-muenster.de>
>
>> Hi Miha,
>>
>> I had a look at your latest code and it looks nice.
>>
>> I have a small questions:
>>   what is the m4/add-test.m4 supposed to do?
>>
> Thank you. This file is a remnant of a different approach I tried, and is
> not used anymore. I will remove it.
>
>>
>> > Right now I'm writing an overview report of a single test run, to see
>> which
>> > tests run the longest, but from this on I'm not exactly sure what to do.
>> > I've deviated considerably from the initial plan, but IMO it's best to
>> > stick with it, and add upload functionality. If you have other
>> priorities,
>> > please tell me.
>>
>> Yes, I think this is the currently. I think we have reached the major
>> milestone. We have a usable performance testing environment. THe next
>> major step will be support for the remote infrastructure.
>>
>> I suggest to add an option to dump the collected results to txt file
>> instead of the database, this way it will be possible to transfer the
>> data using the existing infrastructure. Regarding the format search
>> through my older mails and/or have a look at the dune-autobuild
>> output. If you keep some things flexible, e.g. the exact location of
>> the log files, it shouldn't be too difficult to adjust this to other
>> systems aswell.
>>
> Yes, I will do that.
>
>>
>> Ciao
>> Christian
>>
>> PS: I'm not up-to-date... will you manage to come to the DUNE meeting?
>>
> 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).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20130912/567515b8/attachment.htm>


More information about the Dune-devel mailing list