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

[Geoff Swan <shinobi.jack@xxxxxxxxx>]

   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.
   cheers,
   Geoff

   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
     for
     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
     you
     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
     together
     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
     away.
     The purpose of these will be to give new users an opportunity to
     learn
     the editing tools without having to simultaneously learn how to make
     a
     library.  These libraries should be packaged such that it's easy for
     the user to replace the standard library with them, and immediately
     be
     productive.
     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
     the
      data servers.  Implement a few servers to see how it works.  I've
      started some ideas at
     [2]http://www.delorie.com/pcb/component-dbs.html
      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
      dialog.
     * gnetlist needs the most work.  It needs to be able to read a set
     of
      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
     server
     out there.  Gedasymbols is the obvious candidate, and I can work
     with
     whoever does this task to install any needed server-side logic.
     Someone needs to build a test library where the symbols have
     symbolic
     pin names, and the metadata maps those to physical pins in
     footprints.
     I suggest using the transistor problem as a basis for this library.
     Gnetlist will need to be modified to apply the mappings, although
     for
     this first step, there's no need to include pin or gate swapping
     information.
     Gschem and pcb need a way to swap variants on symbols and
     footprints,
     for example, switching between resistor-1 and resistor-2, or
     RESC1608N
     and RESC1608M.  This depends on the metadata being available
     (above).
     Modify gschem's symbol chooser to allow filtering based on
     attributes
     within the symbol, not just the symbol name.
     I think it would be better if, at this point, people choose tasks
     and
     develop a quick prototype to (1) see if it works, (2) provide a
     basis
     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
     [3]geda-user@xxxxxxxxxxxxxx
     [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

References

   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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user