[openbeosstorage] Re: DiskDevice API 2.3 remarks

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-05-27 at 15:00:03 [-0700], Ingo Weinhold wrote:
> > "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > > * uint8 BDiskDeviceJob::Progress() const;
> > > > I would love to see a float return value. I'd say, the most 
> > > > natural
> > > > range for it was [0, 1], but as BStatusBar's max value defaults 
> > > > to
> > > > 100,
> > > > I could live with that, too. The same goes for
> > > > B_DISK_DEVICE_JOB_SIMPLE_PROGRESS, of course.
> > > 
> > > I would also prefer a float - we shouldn't let the BStatusBar's
> > > habits
> > > rule our world :-)
> > 
> > Oh, no, a misunderstanding: BStatusBar also uses float. It just
> > defaults to the range [0.0, 100.0], while I'd favor [0.0, 1.0]. Not 
> > a
> > big deal, though. :-)
> 
> Well, either way is fine with me; I just picked integers originally 
> because the last status bar control I used (in Windows) used 
> integers. 
> Which do y'all want, though: [0.0, 100.0] or [0.0, 1.0]? Doesn't 
> really 
> matter to me.

As I said, I would favor [0, 1] (for it is the mathematically natural 
representation), but I certainly wouldn't kill for it. ;-)

> On 2003-05-27 at 14:19:59 [-0700], Ingo Weinhold wrote:
[...]
> > * BPartition::ValidateInitialize():
> > Why is it gone? Perhaps there was a reason, but I can't remember.
> > BDiskSystem::ValidateInitialize() is still there, though. If the 
> > method
> > was removed by accident and we want to have both, then they should 
> > have
> > a `const char *parameters' argument (that would be content 
> > parameters,
> > of course).
> > 
> > * Would BDiskSystem::ValidateSet{Child}Parameters() make sense?
> 
> ---------------------------------------------------------------------
> --
> On 2003-04-05 at 12:49:21 [-0800], Ingo Weinhold wrote:
> * ValidateSetParameters(), ValidateInitialize(): I don't think, they 
> make much sense. For one, the `parameters' parameter is not very 
> helpful -- the supplied argument can not be delete, nor the value 
> returned for it instead. More importantly, the only way to get a 
> parameter string is to ask a parameter editor. And it should be safe 
> to 
> assume that it won't return nonsense. If the API user supplies an 
> invalid string, the job simply fails.
> ---------------------------------------------------------------------
> --

Good arguments that I give there. :-P

> Why the BDiskSystem:: version is still around (but without the 
> parameters parameter), I'm not sure. I probably just overlooked its 
> removal. Other than that, I still think it seems reasonable to assume 
> no validation is needed. I'll just get rid of the BDiskSystem:: 
> version 
> unless you object. 

Yep, just go ahead. I'm looking forward to seeing an updated version. :
-P

CU, Ingo

• Follow-Ups:
  • [openbeosstorage] DiskDevice API v2.4
    • From: Tyler Dauwalder

• References:
  • [openbeosstorage] Re: DiskDevice API 2.3 remarks
    • From: Tyler Dauwalder

Other related posts:

[openbeosstorage] DiskDevice API 2.3 remarks

[openbeosstorage] Re: DiskDevice API 2.3 remarks

[openbeosstorage] Re: DiskDevice API 2.3 remarks

[openbeosstorage] Re: DiskDevice API 2.3 remarks

[openbeosstorage] Re: DiskDevice API 2.3 remarks