On Tuesday 18 December 2007 21:18:21 Dave N6NZ wrote:
> peter@xxxxxxxxxxxxx wrote:
> > Hi folks,
>
> <snip>
>
> > What I would quite like to do is to implement something similar to what
> > has been described, especially since I have found a major bug which only
> > (yet another) serious component library API change will fix.
>
> Excellent!
>
> > - What you want the API to be able to do (requirements).
> >
> > - How you want the API to be implemented. Loadable modules? Scheme
> > functions?
>
> I agree that this needs significant discussion and a design document
> before going off to generate a lot of code. Probably also needs some
> prototyped code before committing to a design.
>
> As to backward compatibility, currently my gafrc contains a
>
> (component-library "...")
>
> clause, so perhaps we allow multiple types of component library clause?
We already do.
Actually, it's (component-library directory_path library_name), but the second
argument is optional. You'll see this optional second argument being used to
good effect in the next gEDA release to make the bundled symbol libraries
more accessible.
> Old libs are found the old way, new ones accessed through different
> interface.
I would like the old libraries to be one possible example of the new
libraries.
> I know zero about scheme. So, I don't know if it has a built-in
> database interface or not. But I assume that it either has one, or can
> call out to external shared libraries written in <language of choice>.
> Perhaps something like:
>
> (component-library-helper <name of user supplied scheme function> (
> <function defined parameter list> ) )
>
> and then the user can supply a scheme function with a defined interface.
> We could ship an fully implemented trivial function as an example. The
> user supplied function could connect to a database perhaps, or simply
> call out to a C function. Something like:
>
> (component-library-helper sql-component-lib (host "localhost:5555"
> sqluser "gschem" sqlpw "g5ch3m" database "productionsymbols"))
>
> The Web 2.0 equivalent might be:
>
> (component-library-url "ftp://....";)
Yes, that kind of thing. I'd like to have a common -- and briefer! -- prefix
for component library functions. Perhaps "clib:"?
Also, I like the idea of Scheme functions which call out to external programs
to do the "heavy lifting". We currently do this, but have some problems with
portability -- these are fixable, as long as it's worthwhile.
> I would advocate for the data being cached locally, with a freshness
> test done on startup. I like to travel with my laptop and work off
> line. I'm sure the exact format/protocol of the library found at the
> target of the URL deserves a discussion of it's own.
Maybe we can find a way to make the cache plugable, so that people could use a
database cache or flat file cache if they wanted... something to consider.
Also, what would the semantics be for updating the cache? Would the user
need to be warned that updates were taking place?
> Seems to me that is extensible and backward compatible, and hopefully
> contains enough parenthesis.
>
> Now, what should the chooser do?
>
> The component chooser should be able to work with the attribute editor
> to present the user with drop down boxes populated with sensible
> defaults in the attribute editor.
>
> It should be possible for attributes to be automatically added and
> reconciled. I would like to be able to enter just the part number, and
> have other attributes added/updated to reflect that. For example, in
> my database the part number for a resistor is sufficient to specify both
> value and footprint, so there should be a trigger mechanism that allows
> the attribute editor to automatically update related attributes.
> Obviously, there needs to be a switch to turn this off for cases where
> this side effect gets in the way.
>
> Upon reflection, its clear to me that symbol definition, attribute
> editing, and library access are all interrelated and we want to take a
> holistic view from a user interface perspective.
Which is just what I was saying. :) Could you describe some use cases? For
instance, how would you want to search the library? How would you want to
browse it? How would you want components' attributes to be updated,
automatically, or on user request? How would you want conflicts to be
handled?
These are just a few of the questions that need answering.
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user