Perl SAMP Alpha 3 Español | Deutsch | Français | Italiano | Português

I've just brought my pre-Trieste Perl Hub and test clients into line with the post-Trieste Working Draft document that Mark Taylor pushed to the SAMP mailing list at the tail end of June. Both the Perl Hub and the clients have been tested with Mark's Java SAMP kit pre-release and Luigi Paioro's SAMPY alpha 1 release. This release is being tagged alpha3, and is available under the terms of version 2 of the GPL license.

The new Perl Hub currently lacks callAndWait( ) functionality, I'll be adding that in this week, but should in all other ways meet the 1.0 WD and be interoperable with the other emerging toolkits.

Apart from a quick update towards the end of the week to add callAndWait( ), which will be tagged alpha4, this will be the last 'initial' release. After this I'll take some time to clean up the code, add some documentation, and make the client toolkit a bit more pleasant to use before making a 'first' release.

However if you want to get your feet dirty ahead of that, you'll need the following Perl modules installed: XMLRPC::Lite (part of the SOAP::Lite module), XML::Simple, DateTime, File::Spec, Carp, Data::Dumper, Getopt::Long, Socket, Net::Domain, POSIX and Errno. Depending on your version of Perl some, but not all, of these will ship with the core distribution. The rest can be obtained from CPAN. I think I've caught all the dependancies, but if you notice any I haven't listed any let me know I've forgotten them.

As with my initial release of the prototype SAMP Hub back at the start of May, the code comes with no guarantees except there will be horrendous bugs. There is no documentation. Many of the Perl modules have inline POD, however most of it didn't keep up with the pace of development so it's out of date. However, once you install the additional modules, open up a terminal window and start the Hub as follows,

% tar -zxvf perl-samp-hub-alpha3.tar.gz
% cd perl-samp-hub-alpha3/
% ./samp_hub.pl

you can put the Hub through its paces by opening up two more terminal windows and running the testbed clients. You should start the listener client in all cases,

% tar -zxvf perl-samp-clients-alpha3.tar.gz
% cd perl-samp-clients-alpha3/
% ./listener_client.pl

this is the test client that listens for notify( ) and call( )'s from the Hub. In the second window you can either start the client that exercises the notify( ) method, or the other than exercises the call( ) method. So

% cd perl-samp-clients-alpha3/
% ./callAll_test.pl

or

% cd perl-samp-clients-alpha3/
% ./notifyAll_test.pl

These two clients have a heart beat which will dispatch a call or a notification periodically. The first heartbeat will happen 15 seconds (or so) after the client has completed its registering with the Hub.

As always, feedback is appreciated...

Update: There is now a binary release of the Hub for x86_64 Linux and Intel Mac OSX. Just download the relevant zip file, unzip the executable, and run it. The dependencies, including Perl itself, should be taken care of using the magic of the Perl Packager.

Update: Apparently the x86_64 binary is fairly sensitive to installed library versions. This could just be my unfamiliarity with the packager. Reports of working, and non-working, installations would be good. Advice by people more familiar with PAR::Packer than I am would be warmly welcomed.

SAMP is not Plastic Español | Deutsch | Français | Italiano | Português

Despite not being an official standard the Plastic protocol is one of the more obvious success stories of the Virtual Observatory effort. While it had its flaws, Plastic was easy to implement, and was quickly adopted as the lingua franca for client-side tools to talk to each other.

However in the run up to the Trieste meeting the draft SAMP standard has been released into the wild for comments. SAMP, that's Simple Application Messaging Protocol, is the official successor to the grassroots Plastic standard and shares a lot of common influences and a fair number of the developers.

Over the last few days I've put together a first cut at a prototype SAMP Hub, which will probably eventually after a lot more polishing become one of the reference implementations for the standard, along with some testbed clients.


In the past I've posted about various Plastic and Google related hacks, so its perhaps unsurprising that the first post about SAMP is Google related, and still involves a bit of so called tupperware. To prove to myself that the prototype Hub is actually (sort of) working I've put together a Plastic to SAMP gateway, and a SAMP facade application for Google Sky. After all, I can't go to an IVOA meeting without some sort of gee whiz demo, can I?

Turning Google Maps into Tupperware Español | Deutsch | Français | Italiano | Português

We've know this was coming for a while, but not when. News of Google Maps for Sky leaked out last week on the Google Maps API forum, quickly followed by the official Google announcement on Friday.


You can create a Sky map in the same way you did your plain old regular map, all you have to do is pass it the correct mapType. So something like this will get you a handle to a Sky Map,

     var map = new GMap2(document.getElementById("map"), 
     { mapTypes : G_SKY_MAP_TYPES });

However if you want to do anything to the map, the coordinate mapping isn't pretty. If you've got your RA and Dec in decimal degrees, you'll need to fudge them like this to push a marker pin into the sky,

     var point = new GLatLng( dec, -ra + 180 );
     var marker = new GMarker(point);
     map.addOverlay(marker);

This initially had me very confused, not only is it back-to-front, it's not what you have to do to your RA and Dec to plot it in Google Earth. There you have to subtract 180 from your RA value before throwing it into your KML file. Which of course brings me to KML support, there doesn't seem to be any right now...

The lack of KML support is a bit disappointing, it'd be nice to be able to take the KML network link that has the live feed of event messages flowing across the eSTAR network, and throw it directly into Maps. But right now that isn't possible. No worries though, this is an early release in every sense of the word. It's coming, I'm sure I can count on the Googlers.

With that in mind, it'd be daft for me to rewrite the code to throw the live events into Google Maps, because if KML support is coming, and surely it is, I'd just be wasting my effort. So I decided to sit down and PLASTIC-enable Maps instead. A few months ago I did the same for Google Earth, although obviously I had to take a slightly different tack this time around while turning Google Maps for Sky into so called "tupperware".


As before I've written a small PLASTIC application, a facade, which registers with the PLASTIC Hub as normal and listens for ivo://votech.org/sky/pointAtCoords messages. These are PLASTIC messages telling interested applications to "point at" an RA & Dec. When such a message is passed through the Hub, say by CDS Aladin, it is forwarded to the facade application, which then injects this into a boiler plate HTML file. The facade application then exposes this HTML file via an embedded web server. If you point a web browser at this end point you get a map with the marker plotted at the relevant RA & Dec.

Additionally when you send a PLASTIC message into facade application the place mark it generates has a link which, when clicked, will call back to the facade application's embedded webserver and allow you to send a PLASTIC message back to the Hub. This means there is bi-directional control, both in and out, of Google Maps with PLASTIC.

I've uploaded the source code again, but be warned, this is proof-of-concept stuff and when you're dealing with Perl that can get pretty torturous. Especially since I based it on the previous proof-of-concept code I wrote for Google Earth and never got round to fixing up.

There are obvious problems with my implementation, after all it was just a wet Sunday afternoon's work, but most of these are fixable with a little refactoring. However it does work, and uses a lot of the same concepts as my previous effort. This hints strongly that it really is time I got round to writing that general use PLASTIC module for Perl that I've been talking about for a year or more...

Update: More Google Maps for Sky, this time on the iPod touch.

More Google Sky Tupperware Español | Deutsch | Français | Italiano | Português

My quick hack yesterday where I PLASTIC enabled Google Sky generated a lot of email and encouragement. It also got me thinking about where to go next. However today's adventure in Tupperware I lay entirely at John Taylor's feet, it was his idea, although I must admit I hit myself squarely on the forehead and said "Doh!" when he suggested it...


More Google Sky tupperware...
Unfortunately yesterday's code only allowed Google Sky to listen for incoming ivo://votech.org/sky/pointAtCoords messages. Which isn't really as much fun as sending messages back out. I couldn't see an easy way to do that, but John could,

As for sending points out of Google Sky... you could add a URL to a marker so that when the user clicks on it in Google Sky it opens a web page. In our case we could have it pointing at a local web server that converts it into a PLASTIC message. - John Taylor

Of course that'd work just fine, so I quickly modified yesterday's code to do just that. Now when you send a PLASTIC message into Google Sky the <Description> tag in the Placemark has a link which, when clicked, will call back to the facade application's embedded webserver and allow you to send a PLASTIC message back to the Hub. This means we now have bi-directional control, both in and out, of Google Sky with PLASTIC.

I've uploaded the source code again, but please don't look at it too carefully, it's getting to be quite embarrassing how poorly it's written. I don't normally break object encapsulation like I've done here, but I was really keen to get this working. I've been putting off writing a "proper" Perl PLASTIC module for a while now, looks like Google Sky might be the thing that finally makes me do it...

Anyway, enough for today. Time to sit down and down this properly now I've proved to myself it's possible.

Turning Google Sky into Tupperware Español | Deutsch | Français | Italiano | Português

The PLASTIC protocol is one of the big successes to come out of the IVOA and the VOTech Project. It is a simple to use, and perhaps more importantly simple to implement, communication protocol for client-side virtual observatory tools.

PLASTIC is a protocol for communication between client-side astronomy applications. It is very simple for application developers to adopt and is easily extended. Through PLASTIC applications can do tasks such as instruct each other to load VOTables, highlight a subset of rows or load an image of a particular area of sky. Although such operations are quite simple, they enable powerful collaborations between tools. The philosophy is that the astronomer should have a suite of interoperating tools at his disposal, each of which does one thing well and which can be composed according to his particular needs...

So of course one of the first things that occurred to me when I saw Google Sky was whether it could be made to play nice with all the other virtual observatory tools that are now PLASTIC-aware, and in the process turn it into so called "tupperware".


Google Sky as tupperware
It finally occurred to me this afternoon how you could do it, and I'm a bit embarrassed it has taken this long. I've written a small PLASTIC application, a facade, which registers with the PLASTIC Hub as normal and listens for ivo://votech.org/sky/pointAtCoords messages. These are PLASTIC messages telling interested applications to "point at" an RA & Dec. When such a message is passed through the Hub, say by CDS Aladin, it is forwarded to the facade application, which then builds a KML placemark file. The facade application then exposes this KML file via an embedded web server. If you then point Google Sky at this KML file via a new network link set to periodically update, e.g.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.2" hint="target=sky">
<NetworkLink>
 <name>Plastic Application</name>
 <open>1</open>
 <Url>
  <href>http://localhost:8001/getPoints</href>
  <refreshMode>onInterval</refreshMode>
  <refreshInterval>30</refreshInterval>
 </Url>
</NetworkLink>
</kml>

then any RA & Dec points getting passed through the PLASTIC Hub will start to appear as Placemarks inside Google Sky in more or less real-time. In other words, and to cut a long story short, I've sucessfully managed to PLASTIC-enable Google Sky, at least for inbound messages. Which is good enough to be going on with...

I've uploaded the Perl source code to the simple application which I put together to PLASTIC-enable Google Sky. So if you're a heavy PLASTIC user, and plan to become a heavy Google Sky user too, you might want to take a look. If you do want to run it, the pre-requisite Perl modules are below,

Config::User
File::Spec
Carp
Data::Dumper
Net::Domain
POSIX
Errno
XMLRPC::Lite
XMLRPC::Transport::HTTP
HTTP::Daemon
HTTP::Status

and if you don't already have them, they can be found on CPAN.

Of course with John Taylor having just been hired away from the VO by Google there may be a real PLASTIC interface in Google Sky's future, as John is widely considered inside the IVOA to be the man behind the protocol. Although he'll normally point you to the list of other people involved and shrug his shoulders if you mention that. But in the mean while, I'm pretty happy with my quick hack...

Update: More Google Sky Tupperware...