@cdeil - when I try and start the SAMPHubServer I see the following error:

gaierror: [Errno 8] nodename nor servname provided, or not known

Did you ever see this too?

EDIT: I managed to reproduce this with a simple example and have posted it to stackoverflow: http://stackoverflow.com/questions/20593882/host-returned-by-socket-getfqdn-cant-be-used-to-set-up-an-xmlrpc-server

@cdeil - what was the decision regarding method names? (currently not PEP8-compliant)

@cdeil - FYI I added in the TOPCAT table examples. I tried to simplify them as possible but let me know if they can be made even simpler.

@embray @mdboom @cdeil - there are quite a few places in the code, like this:

https://github.com/astropy/astropy/pull/1907/files#diff-0a3ce8542e196863f25de8c49d57831cR1443

where wrapper methods are defined. What is the most elegant way to avoid this repetitive code? Is this a good place where meta-classes to be used? Another way is to mess with __getattr__ and __dir__ but I wasn't sure if (a) that would be a good idea, and (b) whether it would mess with sphinx.

One option is for the SAMPIntegratedClient class to inherit from SAMPClient. Here's what this looks like:

astrofrog#41

What do you think?

@cdeil - what do you think about splitting up the files further? For example client.py into hub_proxy.py, client.py, and integrated_client? The files are still pretty long.

@astrofrog - re: the GUI stuff: I agree with your suggestion of dropping the Tk dialog and replacing it with terminal interactions.

Or if it's possible/worthwhile to make some sort of optional "hook", then user codes could connect other GUIs as desired (and then the Tk part could serve as an example or test or something). But if that's a lot of work I'd say don't bother right now.

@eteq - sounds good, I've removed the Tk-specific code (it was just a pop-up dialog) and kept the terminal-based workaround that was implemented. We can always add the Tk code back in future if we feel it's needed and we agree on a GUI toolkit.

• +1 to remove the Tk GUI dialog.
• No opinion on splitting hub.py and client.py (currently both ~ 1500 lines) further into smaller files ... go ahead if you prefer this.
• There was no hard decision or strong opinion whether to keep the method names in the current "Java" or "SAMP Standard" format (e.g. class.getMember) or whether to switch to PEP8 names and using properties (class.member). In the end I think there maybe was a slight preference that making it Pythonic would be nicer.
• Subclassing SAMPIntegratedClient from SAMPClient sounds like a good idea, but I don't have time this week to look into the code closely.
• I don't get the gaierror on my Macbook if I run the example you posted on StackOverflow and I haven't seen it before.

I think merging this in astropy master very soon would be good so that it gets some real-world testing before the 0.4 release. It's OK if there are a few known things that should still be improved, e.g. "Make it fully compatible with the protocol v.1.3" as well as more tests and examples can be added incrementally over the next few months.

@cdeil - thanks for your answers! Regarding the sub-classing, I've already done this in astrofrog#41. I'd like to aim to merge this before the end of January, and I agree not all the to-dos need to be implemented before then.

@cdeil - just for info, the hub command-line tool is now samp_hub. The docs for sending/receiving tables have been written, though they may become obsolete if we do #1920 (but they are still useful to see how to send simple messages over SAMP).

I will work tomorrow (while traveling) on PEP8-fying all the method names if there are no objections.

Note to self, the method names still need to be fixed in the docs.

@cdeil - for info, I've worked some more on this and amongst other things have been trying to improve the test coverage significantly. At the moment the coverage is still not great in some files but that is due to some parts of the code running in children threads and pytest-cov doesn't seem to take that into account.

This is going to require quite a bit more work, but I'm hoping that we can have something ready for initial review soon.

@cdeil - I won't have time to work on this much for the next week or so, so if there are any improvements you would like to make, feel free to do so!

One small issue - even though the internet is not needed, there are occasional timeout errors which cause some tests to fail. Shall I just mark them as @remote_data even though they aren't really so? I could restrict this to tests that do occasionally fail?

I've added a few notes but nothing critical that should hold up the PR; it's obviously complex enough that it would take more time than I have to take a more detailed look. Thanks for the fixes to the tests. On my Windows 7 laptop it now takes ~45 seconds for them to run which is quite acceptable.
You've done a fantastic job getting this all set up, as have the package's former owners. Very nice work.

@embray - thanks for the comments! I will implement what I can over the weekend, and will open issues for things that require longer-term refactoring.

@embray - ok, I think I've addressed all of the important issues you raised or moved them to separate issues. Once Travis passes, can I merge? :)

The tests are still passing (the failures a few commits ago were sphinx warnings) so I will merge this later today.