Feature Requests: More Compact ASCII Target Designers .SLX Files

  • Thread starter Thread starter Markus Pietrek
  • Start date Start date
M

Markus Pietrek

Hello folks,

when working with the target designer I always have found that the .SLX
Files in the current way are unable to be handled in a version control
system.

Therefore I'd suggest a few changes

o .SLX files are either binary or ascii. Please provide different
extensions, one for binary and one for ASCII. If a file is opened in
ASCII format, "Save" should store it again in that format.
o .ASCII files, which a RCS can handle, are much too big. I had projects
there an .SLX file was bigger than the actual WinXPe Image.
+ remove (maybe optional) the whitespaces
+ only store settings that are different to the components in the
database
+ keep the order of entries. I had found that after two saves, the
component order in the file had been changed, making it more
difficult for a diff based RCS
o after an image has been built, the .SLX Project is marked changed.
This is due to the build number. I'm always unsure if I haven't
changed unintentional any other settings. Maybe there should be two
markers. One for new built and one for other settings changed
(marked then as "*" )
o allow the "Extra files" order to be placed into the project itself,
not globally for all projects.

Best regards,
Markus
 
Markus,

SLX project files can be saved in XML format from TD (by default it saves projects in binary form). Then you can use any diff tool
you prefer (VSS, WinDiff, cvs diff, etc.) to diff two or more SLX/XML files.
Also, it is often easier to compare project build log files to find out what components have been changed between the builds.
 
Hi Konstantin,

sorry I was unprecises. What I meant with ASCII Files that are too big
(>100MB) are the XML Files (which are actually unicode :-( )

Bye,
Markus
 
Markus,

I see now. It all makes sense what you wrote about XML projects.

However, the fact that the XML XPe project files are often big is not really a disadvantage but rather a trade-off. You got to save
all the included component settings. In big projects there are often huge number of components included. Each component may have its
own set of advanced and custom settings (and even scripts). In order to save it in a text format (ascii, xml, etc.) you have to
include some metadata info and that is where XML helps a lot. However, the file obviously grows much in size since you include so
much info about the data (metadata and etc.). Without that info though the text format may become very restrictive or really hard to
parse.

It also must be Unicode since we are dealing with localized images and can have some settings in languages different than English.
Unicode, of course, brings in its own problems - current VSS versions consider Unicode files as binary and can't do comparison, etc.
Then you got to use some other diff tools that can handle Unicode files (WinDiff, etc.). Obviously, it can make it very inconvenient
because you'd want the diff tool to be integrated with the source control app. Well, I guess, Perforce then can be a better choice.

Thinking about how big XML files may be and how much data and metadata they have to contain I guess there is no easy way to fix
issues within the format itself (even if you switch to another format or will try to keep the order of components within XML, etc.)
and SLX (binary format) can still a better choice for XPe projects.
However, it would be a good idea to implement a SLX/XML diff tool that is properly integrated into TD and, possibly, with the source
control used by the next generation of XPe toolkit. Theoretically, it shouldn't be hard to implement a CMI app (or CMI VB script)
that will do the diff of two XPe projects - compare component lists, find and compare component settings, revs, version numbers -
without a need to show all the metadata details to the developer. However, since currently TD/CD/CDM do not support an open add-in
interfaces, it is hard to integrate the tools with source control.
On a side note, Perforce, for instance, allows creating custom plug-ins to implement a proper diff tool for selected file formats.

My 2 cents...
 
Back
Top