kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

IMHO, RoR can be used to develop web apps faster (not faster web apps..),
and has a wider community and library support, also has libraries to
inteface ruby->python and make use of the kicad scripting wrappers.

But that's just my opinion. Probably, if we get there at any time, it could
make sense to define a common interface (REST?) and basic models, and then
have a good server ecosystem instead of just one, then you connect your
kicad to your favorite part servers.




2013/8/15 Chris Morgan <chmorgan@xxxxxxxxx>

> On Wed, Aug 14, 2013 at 6:29 AM, Miguel Angel Ajo Pelayo
> <miguelangel@xxxxxxx> wrote:
> >
> > 2013/8/14 Chris Morgan <chmorgan@xxxxxxxxx>
> >>
> >> <miguelangel@xxxxxxx> wrote:
> >> > (please use nbee/nbeepass as credentials)
> >> >
> >> > http://kicadhub.com/pcbs/2
> >> > http://kicadhub.com/assembly_guides/3
> >> > http://kicadhub.com/components/107
> >> > http://kicadhub.com/kicadnetlists/2
> >> >
> >> > But at this time I thought that my time was rather limited and that I
> >> > was
> >> > better spending it at kicad itself, finishing and polishing what I
> >> > started,
> >> > so I stopped it.
> >> >
> >>
> >> Interested in putting the server code out there so everyone can take a
> >> look at it?
> >>
> > That's exactly my idea right now, but I must clean up, add license
> headers,
> > and put API keys into config files, and keep empty keys on the repo
> itself.
> >
> >>
> >>
> >> > Now if we mix my old idea, with this new approach:
> >> >
> >> > Everybody has his own github library repositories, and then we could
> >> > build a
> >> > community aggregator, where you can add your git url, it keeps your
> >> > parts
> >> > synced to the aggregator, it also keeps track of voting, pulls your
> >> > library
> >> > updates, and builds an index/categorization that kicad can read,
> >> > then it re-exports on a single github repo (agreggated) and later,
> >> > exports
> >> > an API (extension of the git idea) to keep track of votes, comments,
> >> > etc.
> >> >
> >> > That aggregator might need a server (quite scalable as we relay
> >> > fileserving
> >> > to github), but it must be fully open, same kicad license, so anybody
> >> > could
> >> > build his own server if wanted (for example, within companies...)
> >> >
> >>
> >> Keep in mind that people may do unfortunate things to their github
> >> libraries, such as delete them, change parts etc. That's part of why I
> >> was thinking the server would want to store the data itself.
> >>
> >
> > Yes, most probably would be a good idea keeping all versions of
> everything
> > on the exported git repo, this way you can always access the most popular
> > one or know derivatives. (derivative tracking can be handled on the
> server
> > db)
> >
> >>
> >> The analogy I was thinking of was a pool of parts of varying ratings
> >> and authorship. The server could look to kicad as if it were a single
> >> github repository but could use user accounts to protect against the
> >> wrong people deleting/renaming parts.
> >
> >
> > They can delete/rename parts, but they become derivatives  with a parent
> > part, (just an idea)
> >
> >>
> >> As the api is open there
> >> wouldn't be any issue if someone or some organization wanted to copy
> >> parts from one repository to another but imo if we had an official
> >> kicad blessed repository that might be the central go-to place that we
> >> could build into the plugin as a default source.
> >
> >
> >
> >
> > --
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 636 52 25 69
> > skype: ajoajoajo
>
>
> Please let me know when/if you get this code out there so I can take a
> look. In terms of implementation it might make sense to work with Joe
> Ferner, the guy behind kicadcloud.com, since it looks like kicadcloud
> is trying to do basically what we are trying to do.
>
> Chris
>



-- 

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