Seperation of concerns: FS vs. GUI vs. network daemon

Discuss about the plans: what features to add, how to develop, ...

Moderator: feffer

Post Reply

Seperation of concerns: FS vs. GUI vs. network daemon

Post by dagsverre » Wed May 26, 2004 2:00 pm

First let me say that I'm very happy with PartitionImage, it really came in handy for me. I just thought I'd give some user feedback and suggestions, feel free to ignore it. I know this might be a lot of work, might not be worth it, etc., I'm just making sure the concept has been mentioned.

I merely propose splitting the program up into one command-line tool, and one graphical frontend. The last one could interface with the command-line one or just link with the same library, that doesn't really matter - what matters is the existance of the command-line tool. The command-line tool would not have any network functionality (though if you wanted to keep the network functionality around you could have a seperate command-line client for it, with the GUI using both).

The reasons:
- It is a very strong culture for doing this in Unix. Instead of one program doing it all, you have one program per job and combine them to do the task. This is not a reason in itself, but the culture is there because it has many advantages and has proven itself over time.
- Many (like myself, and I'm certainly not the only one from what I see on the net) use Partition Image primarily in batch mode, from my own script. If you're deploying images across an organization you certainly don't want to be tied down to any certain user interface.

I will take ntfsclone as a very close example. Because it the pluggable-command-line-tool Unix philosophy, you do for instance get encrypted, authenticated network transfer support without ntfsclone even knowing about it. File network transfer is a pretty common problem and I don't see any reason to reinvent stuff... with ntfsclone you simply do:

ntfsclone -o - /dev/hda1 | ssh -C host "bzip -c9 > ntfs.img.bz2"

(The bzip command could be moved to the client instead of the server in some scenarios, based on the CPU power and network load... the point is: It is flexible, the user can decide).

So with one command-line tool they get network transfer over any protocol and with any compression scheme completely free, and can concentrate on one particular task.

Partition Image on the other hand locks you down to a particular scenario: Saving the image to a file or to its own server daemon, using gzip or bzip2 compression. Very convenient for people who want that, but there's no reason not to ship a standard tool doing this with a more flexible basic toolset.

No, this is not simply an attempt to get back to using the shell... such a solution also makes it very easy to create Gnome and KDE frontends to programs without a need to fork off the code with all the maintenance hassles that involves.

// Dag Sverre Seljebotn


Post by DW » Wed Jun 23, 2004 1:05 am

It would seem that the idea of separating the nuts and bolts from the user interface has been raised before: ... um_id=2402

Which reads (in part):
Partimage is a really nice utility, but it would be more useful if the full-screen fireworks were separated from the business end of the program. It would then play better with the rest of Unix.

Posts: 4
Joined: Tue Sep 11, 2007 12:44 pm
Location: Brazil

Re: Seperation of concerns: FS vs. GUI vs. network daemon

Post by igorvc » Tue Sep 11, 2007 12:51 pm

dagsverre wrote: with ntfsclone you simply do:
ntfsclone -o - /dev/hda1 | ssh -C host "bzip -c9 > ntfs.img.bz2"
Try this (Version is 0.6.6 [4.2.1]):
partimage -f3 -z0 -do -B="foobar" save /dev/sdb1 stdout | gzip -c > imageFileWithPipe


I'm hacking the code to accept the stdin to restore this ...

See you ...

Post Reply