Re: Facing the End ;-)

> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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 ;-))

Okay, okay... :-)

> 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).

Yep.

> [...]
> > > 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.

Mmh, you're not really proposing to provide an API for each 
partitioning scheme and file system, are you? I would consider that a 
bit of overkill. In my opinion the GUI add-on is sufficient and 
preferred by 99.99 % of the users. If someone doesn't like it, or has 
plans like mass-partitioning over network, well, the sources are open.

BTW, for the intel partition module, I extracted the reusable code into 
separate source files (intel_partition_map.{h,cpp} for the structures 
and intel_parameters.{h,cpp} for the conversion to and from parameters 
strings), that I intend to reuse in the GUI add-on. I would see 
nothing, that would prevent anyone from using them as well.

> [...]
> > 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.

Yes, that could be done. Though, maybe the FS add-ons are the ones to 
be asked.

> [...]
> > 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.

I somehow doubt, that this will happen. Not that I wouldn't find that 
desirable.

> > 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.

Yes, we will see.

CU, Ingo