Santiago Pericas-Geertsen wrote:
>> I was envisaging that encoding algorithms could be registered with
>> multuple parsers instances (and types of parser) (so can external and
>> initial vocabularies).
>
>
> Ah, I see. Personally, I think that would be a bad idea since it will
> require synchronization and will effectively create a "chicane" in your
> system.
>
OK. Pondering some more.... perhaps the parser/serializer should
maintain a registration of factories for each algorithm and do:
algorithmFactory.getInstance().decodeFrom...
algorithmFactory.getInstance().encodeTo...
I can write a Java proxy class for a generic case in 1.4 (if only we
could use generics!).
(Note the built-in algorithms will not be registered).
Some more thoughts on the EA methods:
For decoding the methods:
public Object decodeFromBytes(byte[] b, int start, int length);
public Object decodeFromInputStream(InputStream s) throws IOException;
both seem useful as a parser can determine from the length of the data
to be read whether a byte array or an InputStream is appropriate.
For encoding the serializer has a choice to use bytes or an
OutputStream. The choice to use which is not so easy to determine as it
would be based given the object on if there is enough room in the byte
array to encode the object. In this respect it may only make sense to have:
void encodeToOutputStream(Object data, OutputStream s) throws
IOException;
For optimized encoding we could extend OutputStream to provide access to
the underlying byte buffer since the encoding algorithm implementation
is in the best position to decide what to do.
I have modified the interface and the int/float algorithms accordingly
(except for an optimized OutputStream extension).
>> It seems that some form of architecture document would be useful :-)
>
>
> Indeed.
>
Yes, time time time....
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109