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

[Christian Engwer]

Hi Miha,

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

I think from the python pov you can write everything in a two modules
and then call either the transport-layer with the db-output, or the
file-output. In the end you have a nice set of python function/classes
and two scripts. One for the full-blown setting, which works nicely
for you and is easily setup on its own and the second script, which
integrates better with current system.

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

will you be able to use the same database, or should we create
seperate databases?

If not, we don't have to invest too much work to keep the systems in
sync. In general I'd suggest to focus on something that
works. Integration with other system can be achieved later.

Keep in mind that "pencils down" is approaching.

Ciao
Christian