m2cw: there is nothing preventing someone from creating an xmload and
xmlsave (except for the ugly names...)
BTW - I think reflection would be an elegant solution ;-D
alan
> -----Original Message-----
> From: Ernest Friedman-Hill [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 10, 1999 4:18 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: JESS: Migrating bload to jess50b2
>
>
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
