kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> The remote aspects of some of the LIB_SOURCEs don't currently seem
> as difficult, and they can be implemented incrementally over a long
> period of time, by any number of people at any time. The design
> enables that. Some of them will require servers on the back end, and
> much help is needed to write those, if they are to get done at all.
> Those servers are not cast in stone, other than they have to work
> with the LIB_SOURCE running on the client, which is in C++. But the
> servers themselves can be in any language, could be python, or an
> apache module, whatever.


I wanted to mention a few items that will help illustrate just how powerful this
design is. 

The unit of retrieval from the LIB_SOURCEs is the Sweet text string.  Essentially that
returned Sweet string is part of the API.  However, behind the mechanism of returning
this string can be anything.  There could for example be a conversion step, converting
the part from any other format into the Sweet form.

Not only is a conversion process possible, but so is a dynamic creation process. 
There is a function to "search for a part using a query string".  But do not limit
that concept to an existing part.

We do not have to limit ourselves to a single "query language".   We could support
several, including a pastebin type ID string.  We just have to use whatever query
language the LIB_SOURCE supports, and I see some supporting more than our standard one.

This is an opportunity to innovate, and to share.

Dick