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


_______________________________________________
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

Reply via email to