Hi Alex, Mariusz,
Whereas I use XML myself for a number of things (including the
preparation and verification of the Jess manual!) I have to agree with
Mariusz here, although not for all the same reasons.
First, using XML for bsaves would place an external requirement for an
XML parser on Jess's users, or at least on those who wanted to do
bsave/bload. I try hard to avoid external requirements because they
generally just lead to problems and confusion.
But secondly, and perhaps more importantly, Java serialization is
"free," while XML encoding would be something I'd have to code
up. True, to maintain version compatibility I'll have to add
serialVersionUIDs and then add read/writeObject methods as things
evolve, but it's still less work than writing the XML code by hand
(also true, you could probably do XML encoding generically via
reflection, but that would undoubtedly be slow and inefficient.)
If all bsave/bload had to do was write out the defrules and facts,
then I could easily use XML, or, for that matter, just Jess code. But
they actually have to write out some representation of the Nodes that
make up the Rete network, including the Node's connections, and their
memories full of Tokens, made up of Facts... Because the Rete network
is not a simple Tree, the code to reconstruct the net from an XML
representation would have to be relatively involved. Java's
serialization code handles this complex interdependent referencing
transparently.
If we -don't- write out a representation of the actual data
structures, then we might as well just write out the rules and
recompile them from textual form. Avoiding this is the whole point of
bsave/bload.
Now, I don't think Serialization is a panacea. In fact, it's not a
good solution at all, really. It's quite slow, and not particularly
space-efficient. But it's an easy one, and it works, so that's what
we've got.
I think Mariusz Nowostawski wrote:
>
>
> 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]
> ---------------------------------------------------------------------
>
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
