Alan Hudson wrote:
> Paul Sandoz wrote:
>
>> Alan Hudson wrote:
>>
>>>> Yes, we have reserved space for additional built-in encoding
>>>> algorithms.
>>>>
>>> ok. I'm going to prototype the BYTE one(pretty easy from the
>>> SHORT/INT code). And I'll report back on how it affects X3D
>>> compression/parsing rates.
>>>
>>
>> OK, so this will have to be an application defined encoding algorithm.
>>
>> I think the support for application defined algorithms probably needs
>> some tweaking for more optimized encoding and decoding. This could be
>> a good use case to test.
>>
> will do.
>
> I'm trying to remember the spec details. By having it be an app-defined
> algo it will be slightly larger right? Ie isn't there a small size
> savings encodings as default?
>
There is no different in size for encoding the encoding algorithm
identifier and the length deliminator of the octets for built-in or
application defined algorithms. The identifier is encoded in 1 byte for
both cases.
Both will require an additional byte compared to a UTF-8 or UTF-16
encoding string.
Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_fi.dev.java.net
> For additional commands, e-mail: dev-help_at_fi.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109