On Monday 04 February 2002 11:59, Tavin wrote:
> On Mon, Feb 04, 2002 at 12:03:49PM -0500, Gianni Johansson wrote:
> > On Sunday 03 February 2002 23:19, you wrote:
> > > On Sun, Feb 03, 2002 at 01:10:25PM -0500, Gianni Johansson wrote:
> > > > FSBucketFactory.FSBucket.resetWrite() doesn't work (NOP) and
> > > > FSBucketFactory.FSBucket.size() returns the buffer size, not the
> > > > amount of data in the bucket.
> > >
> > > Yeah, I know. It's rather an unreasonable interface imho. I have
> > > never needed to use either of those methods. Do you really need them?
> >
> > Yes. They are used by client code. You use Bucket.size() yourself in
> > InternalClient. I don't think Bucket was ever intended to be used by
> > core code (but I'm sure I will hear from Oskar if I am wrong ;-) ).
>
> But the way I use Bucket.size(), the value I want is the total buffer
> size (i.e. after it's filled).
No what you want is the amount of data in the bucket. There is no gaurantee
that the bucket isn't bigger.
> I don't see why you wouldn't want it
> that way. If you've partially filled it and you want to know how much,
> count the bytes yourself.
You don't always know the size of the data when you allocate the bucket.
Scenario:
Client code running inside Nodes JVM wants to use Node.bf for temp buckets.
It allocates buckets which are big enough to handle the largest anticipated
amount of data, but count on .size() to tell how much data was actually
downloaded.
// This works with the current semantics.
Bucket meta = Node.bf.makeBucket(MAX_BUCKETSIZE);
Bucket data = Node.bf.makeBucket(MAX_BUCKETSIZE);
Request req = new GetRequest(5, someCoolURL, meta, data);
if (factory.getClient(req).blockingRun() == Request.DONE) {
System.err.println("bytes of meta data: " + meta.size());
System.err.println("bytes of data: " + data.size());
}
>
> > How do you handle restart after DNV's in InternalClient without
> > resetWrite()?
But how does it work now? Does it work?
>
> The FSBucket semantics effectively imply a resetWrite() call immediately
> before getOutputStream().
This forces you to open and close the OutputStream just to do a reset in
the case where you know that the current data isn't valid (e.g. after DNV).
That seems ugly if you need to mark the bucket empty, but don't nescessarily
have more data to write into it.
>
> What would be a bitch to implement would be making it append if you
> don't call resetWrite(). And I don't believe that's needed anywhere in
> our codebase anyway (i.e., we always want to resetWrite()).
>
You should be keeping track of the amount of data written into the Bucket
anyway, so you can support Bucket.size() correctly. Once you have that data,
why isn't appending anything more than seeking to an offset when the stream
opens?
If you're not already keeping track of the amount of data written into the
bucket does that mean that if I allocate a 256K bucket and then write 3 bytes
into it, the next call to getInputStream() will return a stream 256K long
with only 3 bytes of valid data, and the rest garbage?
Buckets are not for our codebase. They are for client code.
If you want to use something with different semantics in the internals of
your DS implementation, that's fine. Just don't call that thing a Bucket,
make sure InternalClient supports real Bucket semantics, and don't give out
your objects from BucketFactorys.
--gj
--
Freesites
(0.3) freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage//
(0.4) freenet:SSK at npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage//
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
