From: Massimiliano Mirra <list@...>
Date: 2002-03-10T23:53:10+09:00
Subject: Re: [CODE] Opinions wanted (long)

On Sat, Mar 09, 2002 at 12:39:55AM +0900, Yohanes Santoso wrote:
> 1. Consider separating copy and move-ing. People are used to copying
> as an atomic operation. Requiring people to set @copying is an extra
> step that is only superflous.

Uhm, dunno.  This approach actually requires people to Think
Different. ;-) Perhaps @copying is too an un-intuitive name, @is_copy
could be better, the rationale being: do we want to work on the entity
itself or on a copy?

> 2. Consider creating a grouping class. Just like dbase transaction,
> the last COMMIT will #sync every FSE instances in that group. 

That's great.

> Why not
> use Array, you asked. You can, but isn't this nicer:
> 
> #delete files specified in the args
> Group.add(:delete, "/etc/fstab", "/etc/login")
> Group.add(:copy, ["/etc/passwd", "/etc/passwd.bak"], ["/etc/shadow", "/etc/shadow.bak"])
> Group.add(:move, ["/tmp/something", "/tmp/somethingelse"], ...)
> Group.sync #do the above changes
> 
> The advantage of Grouping becomes apparent when you are doing this on
> a remote fs: one long instructions vs. multiple short instructions.
> 
> What to do with exists??? I don't know. I think it should be left
> alone in FSE (i.e., don't make Group support that).
> 
> May be this is a YAGNI (You Ain't Gonna Need It), but how about making
> a DSE class for directories? Or rather soup-up FSE so that it supports
> listing since a dir is a special file.

Well, I tended to follow the file system mechanics in my
implementation and defined a directory like just another file type,
but since the ultimate goal was to handle file system entities just
like objects, I guess it makes a lot of sense to think about
*containers* (not only directories, but maybe archives, too).

Thanks for the insight, definitely useful.

Oh, but now that it dawns upon me, was the answer to whether there is
any usefulness in this concept a ``Yes''? ;-)

Massimiliano