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 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