[lazarus] More on the IDE & component data storage thoughts

[Michal Bukovjan]

Hi,

WARNING !!! - This got longer than intended.

I thought about this some more and would like to wrap up a bit what what
said up to now.

There are 2 major opinions as concerns who will do the work of
remebering components state.

1) IDE-centric - IDE should do the most work, reading/understanding
component properties and their relationship, generating either source
code or XML file, which would get transalted onto source code, and
included into the form source code before the compilation.
2) Component centric - IDE would just create a file/stream and tell the
topmost parent component that it should save its state into the
file/stream and tell its children to do so either.

Ad1] There were objection that doing so with (large) binary data such as
bitmaps may even be impossible. I might add that this method would
probably require some additional RTL support for IDE to understand
custom data types and enumerate its members, such as records. In case of
the source code, this method is only suitable for design-time. Actually,
even in case of XML or other formats, because the application does not
have access to IDE routines when deployed.
The bright side is that it could help somewhat the Lazarus <-> Delphi
compatibility, because the IDE could read/write Delphi DFM files and
decide, which properties to leave out, which Delphi property map to
Lazarus property etc. in case of components that are not fully
compatible with its Delphi counterparts.

Ad2] Since the work of storing data is done by components, this can be
reused later at run-time. The component itself can support its custom
data types, such as records or binary data, in virtual methods like
ReadProperties, WriteProperties. This method would be quite effective
The Delphi compatibility could be preserved, too, but at the expense of
having the differences (property mappings) stuck in the components'
code. The Delphi compatibility (in terms of property mappings) could
optionally be delegated to IDE by having Import/Export project
available, but the programmer would have to maintain two sets of code
then. This method of streaming has further points in easy copying and
paste, cloning controls, etc.

I vote for method No. 2.

Now about storing the components information :

I am far from being an expert on compilers & linker, and I'd like to
know how difficult is to include binary (or, for that matter, text/XML)
resources into the executable. I think Linux / GNU tools does already
have some mechanism of doing this, judging from what I see when
compiling a new version of, for example, Midnight Commander from GNOME.
I can see that there are some pixmaps being linked in (by ld ?), so if
it is there, how difficult would be to make use of this?

And finally, about the method of storing components' metadata:

Source code - desing-time only (--), hard to store binary data, and
custom data types (-), easy to maintain by a text editor (+), gets into
the executable without additional efforts on compiler / linker side (+),
in case of large projects could be a memory hog, though it could also be
faster in some cases (+/-), Delphi incompatibility (+/-), not usable
past the IDE + compiler (-)

XML - usable both in design-time and in run-time (++), clearly defined
way how to store binary data (+), still easy to maintain by a text
editor (+), may get into executable without additional efforts on
compiler / linker - one large ansistring compiled in (+), would require
parsing capabilities inside every application - memory and speed hog
(-), Delphi incompatibility (-), usable in other XML-aware apps (+)

Binary (DFM, or maybe LFM :-) - both design-time and run-time (++),
customizable way to store custom and binary data (+), impossible to
maintain by a text editor (-), required resource management support (-),
fast when loading / saving, no additional overhead (+), Delphi
compatibility (+), unusable in non Lazarus - Delphi apps (-)

As I see it the best way would be component-centric storage capabilites
and some combination of XML and binary support. I don't know much about
inner workings of XML, so I don't know how hard it is to achieve this,
but the best solution would be to have some choice between XML and
binary storage implemented in both TStream and corresponding TPersistent
/ TComponent methods. I think there could be a param in XML-aware
TReader and TWriter, by which they would change its output (something
like binary/text mode in FTP transfers), as well as additional parameter
in TComponents ReadProperties and WriteProperties methods.

Another way could be to have the Stream dynamic filtering capability to
convert to/from binary data written to the stream to/from XML tags on
the fly, although I am not sure if this is even possible.

And yet another idea, the XML-aware part would be in the TReader /
TWriter objects only, they could recognize some common data types
(integer, string, TBitmap, or whatever), and the rest (i.e. custom data
types) could be stored as untyped binary data in case of XML

Heck, the whole thing above could be a 3D chart of pros and cons. Anyone
skilled in critical path analysis and those things willing to apply some
scientific methods to tell us what to do ? :-)

Enough for now, I am hungry :-)
Looking forward to comments,

Michal Bukovjan