[openbeosstorage] Re: Facing the End ;-)
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 15 Feb 2003 18:36:29 +0100 CET
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > I would *love* to see something like that supported at the OS
> > level.
> > Sounds a bit like R2 to me.
> If there'll be resizing support in the file system R1 API, then I
> wouldn't
> stand back regarding the partitioning support. :-P It shouldn't be
> that
> complex (basically the one additional function I mentioned).
Hehe, I think we should really save that feature for R2 ;-))
Of course, we could already think about which functions the file system
API needs to have (and even add them internally; they don't have to
work yet).
[...]
> > Hmmmm, wouldn't this bind you to using the GUI to perform a
> > repartition
> > or resizing=3F Say you have 200 computers, all with identical
> > partitioning schemes, and you want to resize/repartition them all
> > to
> > new sizes, but would rather write a console app to do such a task
> > than
> > manually do it via the GUI on each one of them.
> I understand the concern. The main problem is, that the partitioning
> parameters depend heavily on the specific partitioning system, so
> that we
> can't provide much generic support. What we can do easily and what
> should
> help in the situation described above, is a to add not only a
> Session::Partition() method, but also a
> Session::GetPartitioningParameters(). Then the (not longer) console
> app
> would invoke the latter one once -- the GUI pops up and lets the user
> edit
> the parameters -- and pass the parameters retrieved that way to
> Session::Partition() (a second version with parameters) on all
> computers.
I am not so sure about that... basically, we should be able to hide the
inner partitioning workings from the user. Of course, for so limited
systems as the Intel partitioning scheme, it's beneficial (or even
needed) for the user to specify a partition as primary or active
partition, but I wouldn't enforce a graphical interaction.
Better have a standard structure for every partitioning module that can
be used by a graphical partition add-on as well as a CLI
implementation.
[...]
> Of course you're right, there's one icon for all partition on a
> device.
> The B=5FGET=5FICON ioctl() can certainly be called on the partition
> devices,
> but it finally arrives at the `raw' device driver. Nevertheless I
> think,
> it is a good idea to only have a Partition::GetIcon(). In case, at
> some
> time we have per partition icons, the implementation could be changed
> transparently for the applications using that API. The reason why, I
> find
> a Device::GetIcon() confusing is, that a device exists as an entity,
> but
> it is never presented to the user; only partitions are.
Of course, we could have the partition modules return an icon for their
generic partitions. The B=5FGET=5FICON ioctl() could be redirected to
those.
[...]
> BTW, I also looked through the Tracker sources and it seems, that the
> changes would be quite local: Basically only the AutoMounter would be
> concerned and the MountMenu (a bit). The question of how (if at all)
> a
> common source tree for the different BeOS revival projects (and the
> original BeOS, of course) can be maintained will come up earlier or
> later
> anyway. Supposing that OBOS will be the most BeOS source compatible
> of the
> projects, I think `someone' is looking forward to having a lot of
> fun. ;-)
Oh yeah :-))
If OpenBeOS turns out to be the one and only, we can move the
OpenTracker repository into ours as well, and maintaining it with the
rest of the system.
> What we can probably also do, is to implement the needed parts of the
> old
> API as a (source) compatibility layer...
That might also be a good idea, but we could start without having it.
It might not be needed, after all.
Adios...
Axel.
Other related posts:
