On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck <[email protected]> wrote: > FYI, > > In looking at an http plugin for pcbnew, here are my findings so far: > > It occurred to me that only three class PLUGIN functions seem to be necessary > > *) IsWriteable() this is one line, "return false". > *) FootprintEnumerate() > *) FootprintLoad() > > > So basically two functions. I wrote FootprintLoad() in about 4 hours using > wxHTTP, > complete with "redirect" handling that I added. FootprintEnumerate() is > website dependent > since you have to parse the dir listing coming back. > > > This is a trivial amount of work, but you have something website specific > that is read > only for ever. And that is not a terrible thing, quite useful. > > > Then and found an API at GITHUB, and formulated more thoughts about that, so > what follows > is the formation of a work package: > ============================================================== > > > > http://developer.github.com/v3/ > > > is a marriage made in heaven for pcbnew. The only missing building block is > https > support. We have to parse a little JSON, but this is in boost::property tree > already in > the source tree. > > It also gave me a better handle on the use cases of the fp lib table dialog > window, which > now seems to require a little better support for the options column. I can > envision a > property table two column popup dialog that lets you show the options in name > value form. > (Also maybe an additional PLUGIN api function that returns the options that > each plugin > knows about as fodder for this generic dialog window.) Upon return from the > popup dialog, > you get a string in form > > "option1=value1,option2,option3=value3" > > That goes back into the fp lib table dialog "options" column. > > And of course this property dialog must parse this string upon invocation. > The parser can > be re-used if the results go into a PROPERTIES class instance so it can also > be passed to > the PLUGIN api functions too. > > RE: https. I have a couple of options in mind for that, after which I am > thinking we > could start with a read only GITHUB_PLUGIN implementation, and grow into > something with > write capabilities down the line. > > > I need to solve the https gap in the least painful way. Possibilities I see > are: > > a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, > although > I've yet to verify this is the case when sub-setting it. > > b) cherry pick libpoco, which I have used, and has HTTPS client. > > c) add ssl support on top of wxHTTP using boost and openssl in the same way > boost does it > for non SSL boost::ASIO sockets. > > > These are currently about equal in my mind. Note that merely having SSL > sockets is not as > rich as having an HTTPS client, since much header and replay parsing support > is need. > > If anyone is a networking jockey and wants to work with me on this let me > know. I think I > could and would code the read only form of the plugin in about 2 days if we > had the HTTPS > client support in place. That is bogging me down right now, and brings the > total work to > over 3 days, which I have to defer because of other work. > > > Dick >
I had seen the github api when I was putting together some of the ideas about the online library sharing. It looks like a lot of the approaches they've used could be borrowed. I presume you are referring to using github directly? I was more thinking the api was suitable to build upon for a custom server implementation with additional commands to handle our application specific usage. Chris _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
