[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Task list for: Solving the light/heavy symbol problem

   I don't claim to have any great level of experience in writing APIs at
   all - but I have already started some parts db stuff I would like to
   continue - put me down against some parts db work.

   On Wed, May 25, 2011 at 4:38 PM, DJ Delorie <[1]dj@xxxxxxxxxxx> wrote:

     The "what" phase seems to have drawn to a close, so now it's time
     the "how" phase.  How do we do the things we want to do?  What tasks
     will lead us to the features we want?
     Here, in no particular order, are the tasks I think we need to
     undertake to get started (others will come up as we progress).  If
     were one of the proponents of one of these ideas, it's up to you to
     make sure it happens.  Don't worry about "pretty" - just put
     something that shows off the concept, so we can see it in action and
     evaluate it.
     We need to create a few small heavy symbol libraries.  These are the
     self-contained "starter" libraries we talked about.  Since these do
     not require any software changes, we should start on these right
     The purpose of these will be to give new users an opportunity to
     the editing tools without having to simultaneously learn how to make
     library.  These libraries should be packaged such that it's easy for
     the user to replace the standard library with them, and immediately
     gschem and pcb both need to be better at referencing multiple
     libraries of arbitrary depth.  This includes a better way to manage
     the libraries (gui, config, query rules), enable/disable them, and
     browse them.  This information should be sharable between tools,
     specifically, at least, between gschem, gnetlist, and pcb.
     While I do not wish to start a discussion about what kind of data
     should go in our "metadata", we need tools to work with it.  I think
     that breaks down to the following:
     * On the database end, design an API or two with which we talk to
      data servers.  Implement a few servers to see how it works.  I've
      started some ideas at
      at the "How is the database stored?" text.
     * In gschem and pcb, we need a way to query the data servers in the
      attribute editors, in order to suggest attributes.
     * In gschem and pcb, be able to choose symbols/footprints based on
      metadata queries - use the metadata as a filter for the library
     * gnetlist needs the most work.  It needs to be able to read a set
      rules, query the database, and fill in additional attributes based
      on the rules.  This need not be more than just "fill in the blanks"
      for now.
     gschem, pcb, and the sims need ways to query remote libraries.  I
     suggest HTTP as the protocol, so we can use pretty much any web
     out there.  Gedasymbols is the obvious candidate, and I can work
     whoever does this task to install any needed server-side logic.
     Someone needs to build a test library where the symbols have
     pin names, and the metadata maps those to physical pins in
     I suggest using the transistor problem as a basis for this library.
     Gnetlist will need to be modified to apply the mappings, although
     this first step, there's no need to include pin or gate swapping
     Gschem and pcb need a way to swap variants on symbols and
     for example, switching between resistor-1 and resistor-2, or
     and RESC1608M.  This depends on the metadata being available
     Modify gschem's symbol chooser to allow filtering based on
     within the symbol, not just the symbol name.
     I think it would be better if, at this point, people choose tasks
     develop a quick prototype to (1) see if it works, (2) provide a
     for comparison against other potential solutions.  Less talkie, more
     typie!  ;-)
     Send a reply letting us know what you're working on, to make sure
     nothing gets left out.  It's OK (in fact desirable) to have multiple
     people working on different solutions to the same tasks, so don't
     worry if someone else took your favorite.
     geda-user mailing list


   1. mailto:dj@xxxxxxxxxxx
   2. http://www.delorie.com/pcb/component-dbs.html
   3. mailto:geda-user@xxxxxxxxxxxxxx
   4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

geda-user mailing list