kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck <dick@xxxxxxxxxxx> 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