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

[Miha Čančula]

2013/9/12 Christian Engwer <christian.engwer at uni-muenster.de>

> > Ok. But is basic HTTP authentication with a username (more like computer
> > name, probably) and password enough, or is there need for
> private-key-based
> > authentication? Because if you want the latter, ssh is probably the best
> > way, even though it requires a bit more initial setup.
>
> I think it is good to have both transport channels. If we have an
> alternative http/usename/pwd channel, we can play with this and use it
> for users from other locations.
>
If you think so, I will keep the transport separate from the processing.
This has the added benefit of using the same method as for autobuild.
The downside is the added complexity (not much, really), and not seeing
changes immediately.

>
> One important question is what we do with the data on the receiver
> side. Currently we create lockfile, dump everything in a special
> directory, and create a trigger file. The actual DB-storage is done by
> a different cron job, which handles all trigger files, removes the
> data files and removes the lock.
>
> If you prefere to dump the data to the database directly, you can add
> this feature, but I'd like to have the opportunity to use your http
> transport layer as a direct replacement for our current transport
> layer. This means it should also be able to dump the data to
> individual files.
>
> Please describe your design idea and we can see how this fits to my
> ideas :-)
>
I could do it either way, so if you want to keep the same model I would go
with what you suggest.
Added compatibility and not reinventing the wheel is always good.
I'll dump the data to files in a subfolder of the spool directory, and
process it from there.

>
> Ciao
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20130912/a7d9d844/attachment.htm>