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 <d...@softplc.com> > 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
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp