
|
[openbeosstorage]
||
[Date Prev]
[05-2003 Date Index]
[Date Next]
||
[Thread Prev]
[05-2003 Thread Index]
[Thread Next]
[openbeosstorage] Re: DiskDevice API 2.3 remarks
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 27 May 2003 18:15:37 -0700
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.
On 2003-05-27 at 14:19:59 [-0700], Ingo Weinhold wrote:
> * BPartition::SetParameters():
> It should read `const char *contentParameters'.
Good point, thanks.
> * 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.
-----------------------------------------------------------------------
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.
-Tyler
|

|