On Wed, 10 Nov 1999, S. Alexander Jacobson wrote:
> Let me urge you to serialize into XML rather than using default Java
> seria`lization. The virtue of XML serialization is that deserialization
> will continue to work as long as the data elements the class represents
> don't change. If the internal data representation changes, then you need
> new code either way. The virtue of XML is that you don't get involved
> with class level version number book-keeping that java serialization
> forces on you.
I am (very very) STRONGLY against this idea. First of all, this "b"
in front of "bload" function stands for "binary" (at least for me) which
means: small in size and quick in loading and instantiating. Putting
everything everywhere into XML is not a good approach.
First, what is a sense of putting facts into strings using XML as
facts can be stored easily as strings using Jess syntax anyway (those
which can in XML can in Jess syntax as well).
Second XML parsing (marshaling/unmarshaling) code would increase a lot
Jess footprint, and slow down performance.
Third you cannot put into XML Java objects (real objects, with method
code, etc), which are part of facts sometimes. Thus this "new" XMLish
approach is of limited use.
I agree, that serialization version book keeping is a hassle,
especially during development, but at last it is possible to keep
backward compatibility; and in fact serialization is the good way of
storing dynamic state of the system in mixed Jess/Java environment.
Mariusz
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
