kicad-developers team mailing list archive

[Werner Almesberger <werner@...>]

Dick Hollenbeck wrote:
> Multiple origins of libraries is what we have now. The process to 
> download, install and what not goes away with a proper API.

Okay. If we include the conversion from the real source to the
intermediate format in the set of operations the things beyond
the API perform, then that part is indeed transparent, and what's
left is a packaging issue.

> As soon as 
> a download is done, there is a disconnect between the library maintainer 
> and the downloaded copy.

That's not so good, but I think this restriction would be easy to
eliminate, e.g., by having one or more "edit" operations at the
API.

What would be the general design of that API ? Something like NFS
where you have an opaque token that more or less represents a
pointer to an inode ? So you could

next_inode = change_directory(old_inode, dir_name);
fd = open_file(inode);

and so on.

> I am not volunteering to enhance the module editor, other than to teach 
> it how to use the API.

Fair enough. So, how do we solve the problem that the default - and
implicitly recommended - editor lacks functionality many people
would consider essential for getting the job done then ?

Change the editor, change the default, change the job ? ;-)

> Plugins would be C++ DLL's on windows, or DSOs on *nix. They can make 
> http requests, DBUS requests, ftp requests, nobody cares. They should 
> be cross platform however.

If the types used at the API are simple enough, it should also be
easy to make all sorts of language bindings. Even shell might be
an option, albeit favouring certain platforms :-)

> And I hope somebody like Texas Instruments is reading this, because this 
> is an opportunity for part vendors to distinguish themselves from their 
> competitors. They should be maintaining a footprint library for their 
> parts. Why do we have to do it all? Digikey? Whoever.

Hmm, I wouldn't expect this to happen anytime soon, particularly
not from large companies like TI. I think it's a safer bet for
us to make it convenient to maintain our own component libraries.

- Werner