----- Original Message ----- From: "Dmitri Colebatch" <[EMAIL PROTECTED]> > > > Why cache to XML if you're looking for super performance? Wouldn't > > > serialized objects be even quicker? I haven't a clue how xjavadoc works > > > internally, but my hunch is that it builds an object graph representing > > > classes/methods/fields and their @tag data. > > > > > > Just an idea.... dunno if loading serialized objects is faster than SAX on > > > XML files and rebuilding the object graphi, but seems like it would be. > > > > > > Erik > > > > Hmmm. Serialized objects were used by NetBeans in the early days to persist > > the state of the IDE (user settings, window positioning etc.) and this was > > not exactly successful since new versions of classes are persisted > > differently and incompatibly... > > but thats configuration information yes? In this case, there would be no problem if the cache was corrupt... we can catch the > exception (error? geez... hmmm) and dump the corrupt part of the cache and build again... > > cheers > dim
True, of course! The serialization was used by NetBeans to store lots of configuration settings and even project settings, things that are done mostly manually. Every new release was a PITA to upgrade to! XJavaDoc generates all info that is serialized, so there are no issues here WRT compatibility If compatibility issues arise XJavaDoc would simply delete the 'old' serialized database and run a full parse. However, it might be interesting to use XML as persistency format just to open up XJavadoc to other, non-xdoclet tools (like generating docs using XSLT (actually do anything with XSLT!) or some validation). The most important driver to which persistency format should be used IMHO would be performance. Now Thinking Out Loud: The other driver, not much less important, would be usability! Like I said, using an XML format certainly opens doors to many other tools which process XML like XSLT and Schema validation. Hence, XML should be the number one exchange format between XJavaDoc and XDoclet! Every XDoclet would simply be a SAX ContentHandler and can do the same things they're doing now (generating descriptors, html, sourcefiles) or/and other SAX ContentHandlers (XSLT, validation). Is this just plain stupid or might this actually work!? ciao BG _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
