Topic: Batch processing?

[James Redfern]

Right now, each and every alteration to the configuration is transmitted each and every time a change is made, and the system updates itself in one or many places, rewriting the same files, in some cases, several times over, I imagine.  On a 'slow' system (266Mhz), this wastes time and the impression of efficiency is lost, as it is configured today.  Why not develop a batch procession engine, so that all changes could be made at one time and interactively, so that files are only rewritten once per pass (parse).  This 'Batch Processing' panel could be made so that you cannot leave the Administration Panel without taking a decision either to process or leave until next time.  There may well be other spin-offs this method of processing/updating could provide which I cannot, but you as the developers, may be able to realize.

[Charlie Brady]

James Redfern wrote:

> Right now, each and every alteration to the configuration is
> transmitted each and every time a change is made, and the
> system updates itself in one or many places, rewriting the
> same files, in some cases, several times over, I imagine.

If you can point out any (via bugs@e-smith.com) then we can see if there is a way to remove the duplication.

> Why not
> develop a batch procession engine, so that all changes could
> be made at one time and interactively, so that files are only
> rewritten once per pass (parse).

That's exactly what the system under the hood is meant to do. Files are only rewritten once for each configuration change. Admittedly they are sometimes re-written with the same content, but it is a difficult to impossible problem to determine whether an expanded template will be different without expanding it.

We'd be very happy to receive a patch containing any improvements you can make!

Regards

Charlie

[James Redfern]

Charlie Brady wrote:
> > Why not
> > develop a batch procession engine, so that all changes could
> > be made at one time and interactively, so that files are only
> > rewritten once per pass (parse).
>
> That's exactly what the system under the hood is meant to do.
> Files are only rewritten once for each configuration change.
> Admittedly they are sometimes re-written with the same
> content, but it is a difficult to impossible problem to
> determine whether an expanded template will be different
> without expanding it.
>
> We'd be very happy to receive a patch containing any
> improvements you can make!

Charlie,

Not sufficiently adept the OS or the application to do that I am afraid, but I got the idea from using Partician Magic, where the commands are grouped into a batch and then later, on the click of a button, processed into a rationalised set of instructions.  Right now, in e-Smith, it seems a bit clunky.  If I add a user, then an additional pseudonym and then add a virtual domain and give someone a quota limit, the system has to do each of these operations as a descrete function, I have to wait for each to complete, and I have to do each of these in the correct order or go back and change some entries if I do them in the don't i.e. you can't give a non existant user a quota on, or add a user to, a virtual domain, if you have not created the information bay; or add a user if you haven't created the necesary group, for example.  A batch processing engine would not only be able to analyse and order the collective process and ask you for any necessary additional input, but also rationalize the command structure so that that if there are, say, ten new user names in the batch, the necessary files would be written to only once with all the names.  Much slicker.  Much quicker.

Just thought it would make a neat little addional function that would considerably add to the ease of use.  My 0.2c.  YMMV.

JR.