I am currently developing a collaboration tool (Ki365: Engineering Collaboration Tool Built for KiCad) and would like to know if building a KiCad API compatible remote library solution would be in the best interest of the project. I was wondering if anyone would be able to help answer a few questions:
What is the current state of the HTTP/remote library system? I have read on the developer docs that only part metadata is currently supported. Are there plans/desires/roadblocks for symbol/footprint support?
What would the experience be like if symbol and footprint files were located on a read only NFS drive? Would this be a viable solution in the meantime for setting up remote component libraries?
How well do the current caching mechanisms regarding parts/symbols/footprints3d models operate? If a project connected to a remote database was disconnected, would any data be missing from the local version?
Also, do KiCad users want remote libraries and a polished frontend/backend/ux for this?
I am just a user. So I cannot anwser much of your questions.
I do can tell you:
I believe I am speaking for most users if I say that we are al making and maintaining our own personal libraries.
When doing so, I try to re-use the native Kicad library element. To safe me some troubles of drawing me an OPAMP. These libraries come with the download of KiCad. When you install or update, you have a relatively fresh library, which is trustworthy for me… so far
I am usually connected to the internet. So I don’t really care that much whether my default parts come from the default library on my hard drive as is now. Or come from the internet.
There are however a few occasions that home wifi just… won’t go. If I could not resume work when internet is down, all hope is lost. I deem it unacceptable for me to rely on a stable connection to some server somewhere in the world to be able to do my work.
Also, do KiCad users want remote libraries and a polished frontend/backend/ux for this?
I do can live with downloading some library when I do have internet, store it locally and add whatever I need from it to my personal libary. So yeah, if you host some good libraries. I would love to perform a git pull (no need for some fancy UI) from time to time from your server.
Having all I need already in the default libraries I see no need for a copy of this database on some webpage. (I would personally benefit more from more librarians adding to this library so I have more stuff avaible to me with the next update of KiCad).
I maintain my libraries on my dropbox folder. So if I make some element @work, I have it @home as well. So I am not against cloud storage, I am just in favor of having my stuff on my local hard drive while doing work.
HTTPLIBs allows making a library of “cross-lib” symbol aliases (you couldn’t do this otherwise, you can’t make an alias of Device:R with just different metadata in your own lib, you have to clone the actual Device:R symbol into your lib). Now a single HTTP lib can use any of the stock lib (or your personal lib) symbols as a base and sprinkle metadata on top
it’s metadata only, you cannot actually make a complete custom symbol, you have to use a normal symbol as a base
the “link” is done via a TCP socket, thus a HTTPLIB server could be run locally for single-person scenarios even, or for multiple people and maybe over the internet (this is not my focus thus i don’t know how good this idea is yet)
HTTPLIBs would allow making atomic component libraries - where each component has complete information for a real part, including MPN, MFR, accurate description (including parameters), SKU codes for different distributors, etc…
function-wise kicad asks the server for 3 kinds of things:
Get a list of categories - a single HTTP lib can return one or more categories, and they appear in kicad as sepparate libraries in the form “MyHTTPLIB - Category1”
Get a list of components from category X (where only minimal part information is requested)
Get the full information about a single component
when you merely open the symbol editor, kicad “scans” your HTTP lib by using requests #1 and #2, while request #3 happens when you click on one of the symbols
now, i do have some questions because so far the information i found was kinda slim and i see a few weird things, i hope maybe someone from the Dev team sees this:
requests #2 and #3 allow the server to reply with different values for name and description. the info from request #2 is what’s used to populate the big list in the symbol editor, but the info from request #3 is what actually gets populated into the symbol when you add it to the schematic - is this intended?
if this is normal then i am tempted to show different information “in the list” (request2) if that can help the user to find the part he wants
the basic symbol fields (footprint, datasheet, etc…) have text objects in the symbol and are usually set to Hidden for most stock symbols. However, when you use such a symbol as a base from the HTTPLIB the visibility of those texts turns “on” by default unless you specify it as “off” which is IMO very weird… the symbol author has made a choice whether those basic fields should be visible on the schematic or not, why don’t this stay the same when the symbol is used thru HTTPLIBs? is this a bug?
it’s a bit unclear which fields should be included in request #2, the example only shows name and description (since those are visible in the big list), but then how would keywords work? i already submitted an issue about this
in request #3 there’s a footprint field, which works like you’d expect - it sets (overrides) the footprint of the symbol, but then the original symbol’s “footprint filters” no longer work, so you only have that one footprint in the symbol picker. I would’ve expected that the original symbol’s footprint filters still worked, and that the HTTPLIB could specify custom ones. For example Device:R has all kinds of resistor footprints, if you’re making an atomic symbol for a 0603 resistor you would set the default footprint to a 0603, but you then do not want the normal footprint filters to work so the user doesn’t by accident choose a different size. It might be a good idea to let the HTTPLIB supply different filters to allow the “hand-soldering” version of the 0603 footprint tho… so i would’ve expected that when the HTTPLIB supplies custom footprint filters - only those apply, otherwise the original symbol’s filters apply
