kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

I love the plan, it matches and extends the tiny idea I had but it's well
planned!!,

  About the SWEET_HTTP_LIB source and even SWEET servers, and web apps,
I propose that we could use our (future) new python powers, that are
proficient
in handling XML-RPC, Databases, and similar things with very very few lines
and
effort.

    I have a lot of experience about python+networking+xml-rpc+web
apps, and
if using the underlying python scripting could fit on the plan, then we
will just run ...
and enjoy our popcorn more happily.


   Cheers,
Mike


2012/4/9 Dick Hollenbeck <dick@xxxxxxxxxxx>

> On 04/09/2012 02:55 PM, Miguel Angel Ajo Pelayo wrote:
> > Now that may be we're still in time (well in fact, now I think that
> could be added
> > lately without big impact..)
> >
> >       What do you think about adding a UUID (I see now that you used
> 'LPID' for SWEET)
> > to the PCB files, and also a revision number (that goes incrementally on
> every modified
> > save).
> >
> >      Also adding LPID to module/footprints would be great, think of the
> concept for one
> > moment:
> >
> >
> >         You could be able to keep your brd files in a database (also
> distributed), and
> > check if your board version is the latest available, even ask for
> upgrade from kicad.
> >
> >         Also, with LPID + rev number in the modules/footprints, you
> could ask KiCad to
> > interactively update your footprints from the
> > ones you have in the database. For example, somebody in your company
> could have updated
> > certain footprint to enhance manufacturability or fix a silly
> orientation bug... etc.
> >
> >        I see a world of opportunities just adding:
> >
> >             * LPID (or UUID)
> >             * File Revision Number (automatical/autoincremental)
> >
> >      And also keeping inside the .brd file:  LPID + Rev Number of every
> module.
> >
> >
> >      I really love this idea, and I see that you already thought of it
> for sch / lib parts.
>
>
> Welcome to a 4 year old conversation.  Your conceptual grasp is large.
> But the
> conversation is old.   I thought about a UUID, but I invested money in an
> LPID.  Does that
> answer your first question adequately?
>
>
> To summarize my feelings:
>
>
> a) what we have in SWEET is revolutionary, since we bring in inheritance,
> distributed
> LIBs, and versioning.  Please watch for bullshit patents popping up on it
> to help me out.
>
>
> b) the opportunity and needs in PCBNEW are comparable or greater than in
> EESCHEMA, I have
> tended to think of the task as "bigger than EESCHEMA".  This is a reason
> why I started
> with EESCHEMA, because I was certain that we'd learn things there that
> would be helpful
> when PCBNEW was re-worked.   I have no interest in deviating from this
> original strategy
> because of that single reason.
>
>
> c) Once you add a logical library name, you can then abstract its
> implementation and location.
>
>
> d) Just last week, Jean-Pierre, Wayne and I exchanged emails on bringing
> in a logical
> library name into the *.kicad_brd to better identify the origin of a
> footprint within a
> board.  I think there is support for just this little bit for now.   The
> prior sentence is
> the most important one in this email, please read it again.  Certainly
> doing more would
> require more brain cycles than are available at this time, and can always
> be done down the
> road in PCBNEW.  I was hoping to abstract the library access methodology
> in the PLUGIN
> API, without going to the extent that I am in SWEET.   For s-expression
> libraries, we are
> currently thinking of simply having a directory of s-expression (module)
> files, rather
> than a file of footprints.  So a footprint library is merely a directory.
>
>
>
> This is a scouting report, it does not preclude conquering the world at
> some future
> point.  But please realize that my commitment never even extended to even
> completing SWEET
> myself, let alone anything to do with PCBNEW.  Said differently, my SWEET
> design needs
> implementors beyond myself to complete.   SWEET does not apply and cannot
> apply directly
> to PCBNEW, although much that is learned there could eventually be used in
> PCNEW.
>
>
> The only reason we are cramming in the new file format now was the
> avalanche of the
> nanometers entering PCBNEW, did not want to disrupt user's lives
> inconsiderately with
> multiple file format changes.
>
>
> In summary, we are left dreaming and imagining, but get to each a little
> popcorn while we
> are doing it.
>
> My commitments are pretty well documented, and trying to commit resources
> that I do not
> have control over is foolish.
>
> In lose terms, given *current resources* this is what I see:
>
>  PCBNEW minimally ---> EESCHEMA radically ---> PCBNEW better much later
>
>
> There are many things where we need help:
>
> nanometers:
>
>  UI, DRC, dialogs, zoom, grid, status display of perhaps increasing drill
> down resolution
> as we zoom in.
>  specctra export, gerber testing, etc.
>
>
> EAGLE PLUGIN:
>
>
> SWEET HTTP_LIB_SOURCE, which is likely to be a hell of a lot of fun.
>
>
> Dick
>
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo