Alan Hudson wrote:
>> I think i already need to make one modification to the encodeToBytes
>> method. It is not possible to obtain how many bytes have been written.
>
>
> Does this method follow standard java rules of not reallocating of the
> array is big enough?
Yes.
> Instead of a wrapper class, how about a
> getNumberBytesWritten to get the last number of bytes?
>
But then it would not necessarily be thread safe.
Perhaps it might be better to mandate the use of a holder for the input
with the return of a boolean value if reallocation occurs and the state
of the holder changes?
>> We need a simple ByteArray holder class to be returned for this.
>>
>> Alan, would this meet your requirements for X3D?
>>
> I think so.
OK.
> I'm still a week away from moving my code over. Sorry for
> the delay.
>
No problem.
> Having both the byte and stream version will require some extra coding
> but its likely worth it for the flexibility. Internally I think I just
> handle streams right now.
Should be easier to reuse the stream implementations for those cases
with generic methods if you do not want to provide an optimal case.
I see the 'stream' methods as being most useful for generic cases where
it is not know how large the encoded content will be and it is not
possible to get an upper bound on the size given the input. Thus these
methods would be used by the parser/serializer for registered
algorithms. Whereas the 'byte' methods can be used by the application
for optimal scenarios.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109