kicad-developers team mailing list archive

[Povilas Kanapickas <povilas@xxxxxxxx>]

I'd like to propose a new format for components libraries. The summary
of the proposal is as follows:
 * XML is used as the serialization format
 * one directory per library
 * one file per component
 * boost::property_tree is used as internal, abstract data format. This
allows translating to/from multiple file formats at the point of load/save.

I'm volunteering to implement a new library parser/writer and convert
all existing libraries to the new format, if the proposal gets accepted.

We could potentially introduce something very similar to the Github
plugin for component libraries too, however this is not part of this
proposal.

The detailed proposal is as follows:
 * A library in the new format would be defined as a collection of files
in a directory. A directory would contain:
   + A file with extension '.kicad_symlib', in which some library-wide
information is specified
   + A collection of files with extension '.kicad_sym', each of which
define one component.  I think it's worth to merge the component symbol
and the docs into a single file because:
     - Everything could be kept in a single place
     - The number of files would be reduced
     - The docs don't take much space anyway
 * The .kicad_symlib file would not list the symbols contained in the
library. The library parser should list all files within the directory
and try to parse each file with appropriate extension.
 * The file name would be derived from the component name.
 * The format of the files would be XML. This has the following advantages:
   + The format would be at least somewhat self-documenting
   + The format would be easily extensible
   + The format would allow much better interoperability with other
software, as tool/library support for XML is in great shape.
 * Indentation amount would be set as a policy to eliminate any problems
during merges to the repository. The same for newline locations. I
suggest two spaces and one tag per line respectively.
 * XML namespaces won't be used since they are not useful in this
particular use-case, yet would make the files less convenient to parse
using certain libraries.
 * boost::property_tree library would be used as a parser. It is already
used in the KiCad codebase.
 * The saving and loading routines would be modified to accept a path
instead of a generic stream. CMP_LIBRARY::{Save,Load} and
{Save,Load}Docs would be merged each with their respective sibling.
 * The users of CMP_LIBRARY::{Save,Load} would not know exact layout of
the library. Existing functionality that depends on the layout would be
moved to within CMP_LIBRARY. For example, a new method
CMP_LIBRARY::Backup would be introduced.
 * At first, parsers of both formats would be implemented as member
functions of CMP_LIBRARY. Once everything is tested, we could create a
plugin interface.
 * New {Load,Save} overloads that accept boost::property_tree would be
created for all LIB_* types that support serialization. Eventually,
write support for old format would be removed: the format would be
supported by translating it to boost::property_tree at a single,
centralized location (though bidirectional translation is possible too,
if needed). We could support lots of other formats this way.

What do the developers think about this proposal?

Regards,
Povilas