FreeLists / openbeosstorage / [openbeosstorage] Re: DiskDevice API v2.1

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> > > If
> > > that
> > > would require absolute blocks, we should go back to the drawing
> > > board
> > > :)
> > 
> > If UDF does, I would vote for omitting support for it out of 
> > principle
> > (if necessary, locking Tyler into some basement without computers).
> > ;-)
> 
> :-P That's a really bad idea all around. :-)
> 
> Seriously, with no UDF support, you have no DVD support. And iso9660 
> is
> no better, and we sure aren't dropping CD support. How about
> BDiskSystem::UsesAbsoluteAddressing()?

Let me clarify this a bit (I was in a bit of a hurry last night... 
:-/). We could support generic moving for any disk system that didn't 
require absolute addressing. For those that do, they can either support 
moving themselves, or just be immobile (which, as Axel pointed out 
earlier, won't matter in most cases anyway since they'll usually be on 
optical media anyway).

> > > > > class BDiskSystem {
> > > > > public:
> > > > >     bool SupportsParentSystem(const char *system) const;
> > > > >         // True in most cases. NULL =3D3D=3D3D raw device.
> > > > >     bool SupportsChildSystem(const char *system) const;
> > > > >         // False for most file systems, true for most
> > > > >         partitioning
> > > > >         // systems.
> > > > >
> > > > >     bool IsPartitioningSystem() const;
> > > > >     bool IsFileSystem() const;
> > > > > };
> > > > As said above, I would make them virtual. Moreover, the 
> > > > Supports*
> > > > System()
> > > > should also have a BPartition* parameter. Otherwise partitioning
> > > > systems
> > > > that allow only a limited number of levels can't give an
> > > > authoritative
> > > > answer here. The BPartition* parameter could optionally be NULL 
> > > > to
> > > > ask
> > > > whether it is supported in general.
> > > 
> > > I think there should be read-only set of classes, and an 
> > > additional
> > > add
> > > -on based set to actually do any changes. This will be only rarely
> > > used, so it probably doesn't make much sense to clobber the 
> > > general
> > > API
> > > with it - so I like something BDiskSystem (as a virtual (and
> > > abstract)
> > > base class), but it should contain everything, and not only the
> > > check
> > > operations.
> > > Thoughts=3D3F
> > 
> > You mean that e.g. BPartition::Move() would be ommitted in favor of 
> > a
> > BDiskSystem::Move(BPartition*,...)=3F
> > Mmh, that doesn't sound very convenient.
> 
> No, I don't think I like that either.

And to clarify a little here, having immutable classes that are updated 
via a separate interface makes it more difficult to batch complex 
operations on partitions that don't exist yet (i.e. creating and 
initializing a bunch of new, even nested partitions). I don't really 
feel like the general API is being clobbered here, just further 
augmented.  

-Tyler