
|
[openbeosstorage]
||
[Date Prev]
[04-2003 Date Index]
[Date Next]
||
[Thread Prev]
[04-2003 Thread Index]
[Thread Next]
[openbeosstorage] Re: DiskDevice API 2.2 remarks
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 08 Apr 2003 23:14:02 +0200 CEST
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-04-08 at 12:01:20 [-0700], Ingo Weinhold wrote:
> > Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > [...]
> > > > > BDiskDisk:
> > > > > ---------
> > > > >
> > > > > * What meaning has the `checkOnly' flag of
> > > > > SupportsRepairing()=3F
> > > > > Same
> > > > > in
> > > > > BPartition::[Can]Repair().
> > >
> > > Well, I was thinking of offering the ability to make read-only
> > > repair
> > > runs, i.e. verification runs. I'm not sure that's really
> > > necessary
> > > though.
> >
> > Ah, OK. Doesn't harm at least. BTW, the idea is to send encountered
> > errors via notifications? I hope that doesn't have impact on
> > performance.
>
> Yes, but only to the provided progressMessenger, not through the
> watching system.
So, other notification subscribers could not get these data? IIRC, I
already proposed to add a B_DEVICE_JOB_PROGRESS notification "event"
field value and a respective event mask flag (can't find the mail --
maybe I was just dreaming). A B_DEVICE_JOB_DETAILED_PROGRESS plus event
mask flag could be added, too. Moreover I start to feel, that a
BDiskDeviceRoster::StartWatching(BDiskDeviceJob*,...) version might
make sense. What do you think?
[...]
> > > > > It may be better to introduce
> > > > > [Can]Delete() instead (or additionally).
> > >
> > > Well, I had those in there, but I felt they fell under the same
> > > argument as the one use for eliminating
> > > BPartitionableSpace::CreatePartition(), i.e. the BPartition is
> > > suddenly
> > > going to disappear or at least be invalid.
> >
> > Although at least the name Delete() should be hint enough for the
> > user
> > to not be too surprised. ;-) However, since one can only delete
> > child
> > partitions (not devices) DeleteChild() is probably better. Maybe we
> > should add an additional DeleteChild(BPartition *child) version.
>
> DeleteChild(child->Index()) ?
Okay, okay, you win. :-)
[...]
CU, Ingo
|

|