From m.b.taylor at bristol.ac.uk Tue Dec 2 01:37:32 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 2 Dec 2008 09:37:32 +0000 (GMT) Subject: JSAMP hub and localhost hostname In-Reply-To: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > Hi Mark, > > I've been testing and playing with (J)SAMP the last days, and I had the > following problem : > > - let's pretend I am connected to a wireless network whose DHCP server gives > me hcp-131-176-166-130.esac.esa.int as hostname > > - if I launch a JSAMP hub, the lockfile will have the following line : > samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ > > - now, if I disconnect from this network, and startup Aladin, it won't be > able to connect to the hub because it won't be able to resolve the XML-RPC > URL hostname. > > So, my question is : wouldn't it be safer to use the IP address instead of > the hostname ? > > Subsidiary question : I noticed that sometimes, the Java method > InetAddress.getLocalHost() throws an UnknownHostException (I use this method > to set the callback URL of Aladin). In such a case, how safe is it to > consider 127.0.0.1 to be the localhost IP address ? > Though I am not a network expert at all, I feel this would do the right thing > most of the time. Any opinion on that ? Thomas, good questions, not all of which I have good answers to. I'm bouncing this onto the apps-samp list in case others have thoughts or benefit from the discussion. First, this is an issue that we've come up against before in AstroGrid in relation to the AG PLASTIC hub and the VODesktop/AR XML-RPC server. The consensus seems to be that there is no best way to do it - any single approach will fail under some network setups (see the followup bugzilla tickets in the snippet below). With that in mind, I've tried to cover all bases in JSAMP by making this configurable. When JSAMP writes the hostname into the hub lockfile, it uses the SampUtils.getLocalhost() utility method, whose javadocs and source currently read like this: public static final String LOCALHOST_PROP = "samp.localhost"; ... /** * Returns a string denoting the local host to be used for communicating * local server endpoints and so on. * *

This is normally obtained by calling *

      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
      * 
* but this behaviour can be overridden by setting the * {@link #LOCALHOST_PROP} system property to the string which should * be returned instead. Sometimes local network issues make it * advantageous to use some non-standard string such as "127.0.0.1". * See, for instance, AstroGrid bugzilla tickets * 1799, * 2151. * * @return local host name */ public static String getLocalhost() { String hostname = System.getProperty( LOCALHOST_PROP, "" ); if ( hostname.length() == 0 ) { try { hostname = InetAddress.getLocalHost().getCanonicalHostName(); } catch ( UnknownHostException e ) { hostname = "127.0.0.1"; } } return hostname; } So, if you understand the problem you can fix it by running the hub with the system property samp.localhost=131.176.166.130 or whatever you reckon will work. This is a good start, but the trouble is people who don't understand the problem (=most users) won't know what's up or how to fix it. So there might be improvements to be made in advertising this functionality or in choosing a safer default. Ideas from anyone who, after reading the bugzilla tickets referenced above, thinks they might have a contribution, are welcome. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From fernique at simbad.u-strasbg.fr Tue Dec 2 02:55:06 2008 From: fernique at simbad.u-strasbg.fr (Pierre Fernique) Date: Tue, 02 Dec 2008 11:55:06 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: <4935140A.9060903@simbad.u-strasbg.fr> Hi all, My experience with the GLU project: surprisingly, it is difficult to have a simple method for getting a correct full local hostname and it is worst if you want to be sure that this hostname is correctly registered in the DNS (correct alias for the IP). I strongly suggest to use 127.0.0.1 as PLASTIC/SAMP is presently really designed for local access. The 127.0.0.1 is managed at the IP stack level. So it is always responding even if you have several network cards or no card at all. It is constant (DHCP potential problem). And it should solve some potential firewall filter problems and potential security holes. In the future, if we want to extend SAMP for remote connections we could invent a kind of gateway plugged on the hub and managing all the required remote registrations, remote authentifications ... I wonder if a dedicated SAMP client could do this job? But in any case, by using 127.0.0.1, we will fix a lot of potential problems. Cheers, Pierre Mark Taylor a ?crit : > On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > >> Hi Mark, >> >> I've been testing and playing with (J)SAMP the last days, and I had >> the following problem : >> >> - let's pretend I am connected to a wireless network whose DHCP >> server gives me hcp-131-176-166-130.esac.esa.int as hostname >> >> - if I launch a JSAMP hub, the lockfile will have the following line : >> samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ >> >> - now, if I disconnect from this network, and startup Aladin, it >> won't be able to connect to the hub because it won't be able to >> resolve the XML-RPC URL hostname. >> >> So, my question is : wouldn't it be safer to use the IP address >> instead of the hostname ? >> >> Subsidiary question : I noticed that sometimes, the Java method >> InetAddress.getLocalHost() throws an UnknownHostException (I use this >> method to set the callback URL of Aladin). In such a case, how safe >> is it to consider 127.0.0.1 to be the localhost IP address ? >> Though I am not a network expert at all, I feel this would do the >> right thing most of the time. Any opinion on that ? > > Thomas, > > good questions, not all of which I have good answers to. I'm bouncing > this onto the apps-samp list in case others have thoughts > or benefit from the discussion. > > First, this is an issue that we've come up against before in AstroGrid > in relation to the AG PLASTIC hub and the VODesktop/AR > XML-RPC server. The consensus seems to be that there is no best way > to do it - any single approach will fail under some network > setups (see the followup bugzilla tickets in the snippet below). > With that in mind, I've tried to cover all bases in JSAMP > by making this configurable. When JSAMP writes the hostname into > the hub lockfile, it uses the SampUtils.getLocalhost() utility method, > whose javadocs and source currently read like this: > > public static final String LOCALHOST_PROP = "samp.localhost"; > ... > > /** > * Returns a string denoting the local host to be used for > communicating > * local server endpoints and so on. > * > *

This is normally obtained by calling > *

>      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
>      * 
> * but this behaviour can be overridden by setting the > * {@link #LOCALHOST_PROP} system property to the string which should > * be returned instead. Sometimes local network issues make it > * advantageous to use some non-standard string such as "127.0.0.1". > * See, for instance, AstroGrid bugzilla tickets > * * >1799, > * * >2151. > * > * @return local host name > */ > public static String getLocalhost() { > String hostname = System.getProperty( LOCALHOST_PROP, "" ); > if ( hostname.length() == 0 ) { > try { > hostname = > InetAddress.getLocalHost().getCanonicalHostName(); > } > catch ( UnknownHostException e ) { > hostname = "127.0.0.1"; > } > } > return hostname; > } > > So, if you understand the problem you can fix it by running the hub > with the system property samp.localhost=131.176.166.130 or whatever > you reckon will work. > > This is a good start, but the trouble is people who don't understand > the problem (=most users) won't know what's up or how to fix it. So > there might be improvements to be made in advertising this > functionality or in choosing a safer default. Ideas from anyone who, > after reading the bugzilla tickets referenced above, thinks they might > have a contribution, are welcome. > > Mark > From luigi at lambrate.inaf.it Tue Dec 2 03:10:38 2008 From: luigi at lambrate.inaf.it (Luigi Paioro) Date: Tue, 02 Dec 2008 12:10:38 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: <493517AE.2020604@lambrate.inaf.it> Thank you Mark for having posted this issue on the SAMP mailing list, it gives me an answer to an old problem Alastair Allan had with SAMPy on his laptop at home (maybe he remembers the problem), and I think the only reasonable solution to adopt is that that you indicated. I've just fixed SAMPy in order to try to get the host name using the standard socket library, but if it fails than, by default it is used 127.0.0.1. The next SAMPy release, that will come when the SAMP document v1.1 will be promoted to Recommendation, will include this feature. Luigi Mark Taylor ha scritto: > On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > >> Hi Mark, >> >> I've been testing and playing with (J)SAMP the last days, and I had >> the following problem : >> >> - let's pretend I am connected to a wireless network whose DHCP server >> gives me hcp-131-176-166-130.esac.esa.int as hostname >> >> - if I launch a JSAMP hub, the lockfile will have the following line : >> samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ >> >> - now, if I disconnect from this network, and startup Aladin, it won't >> be able to connect to the hub because it won't be able to resolve the >> XML-RPC URL hostname. >> >> So, my question is : wouldn't it be safer to use the IP address >> instead of the hostname ? >> >> Subsidiary question : I noticed that sometimes, the Java method >> InetAddress.getLocalHost() throws an UnknownHostException (I use this >> method to set the callback URL of Aladin). In such a case, how safe is >> it to consider 127.0.0.1 to be the localhost IP address ? >> Though I am not a network expert at all, I feel this would do the >> right thing most of the time. Any opinion on that ? > > Thomas, > > good questions, not all of which I have good answers to. I'm bouncing > this onto the apps-samp list in case others have thoughts > or benefit from the discussion. > > First, this is an issue that we've come up against before in AstroGrid > in relation to the AG PLASTIC hub and the VODesktop/AR > XML-RPC server. The consensus seems to be that there is no best way to > do it - any single approach will fail under some network > setups (see the followup bugzilla tickets in the snippet below). > With that in mind, I've tried to cover all bases in JSAMP > by making this configurable. When JSAMP writes the hostname into > the hub lockfile, it uses the SampUtils.getLocalhost() utility method, > whose javadocs and source currently read like this: > > public static final String LOCALHOST_PROP = "samp.localhost"; > ... > > /** > * Returns a string denoting the local host to be used for > communicating > * local server endpoints and so on. > * > *

This is normally obtained by calling > *

>      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
>      * 
> * but this behaviour can be overridden by setting the > * {@link #LOCALHOST_PROP} system property to the string which should > * be returned instead. Sometimes local network issues make it > * advantageous to use some non-standard string such as "127.0.0.1". > * See, for instance, AstroGrid bugzilla tickets > * * >1799, > * * >2151. > * > * @return local host name > */ > public static String getLocalhost() { > String hostname = System.getProperty( LOCALHOST_PROP, "" ); > if ( hostname.length() == 0 ) { > try { > hostname = > InetAddress.getLocalHost().getCanonicalHostName(); > } > catch ( UnknownHostException e ) { > hostname = "127.0.0.1"; > } > } > return hostname; > } > > So, if you understand the problem you can fix it by running the hub > with the system property samp.localhost=131.176.166.130 or whatever > you reckon will work. > > This is a good start, but the trouble is people who don't understand > the problem (=most users) won't know what's up or how to fix it. So > there might be improvements to be made in advertising this functionality > or in choosing a safer default. Ideas from anyone who, after reading > the bugzilla tickets referenced above, thinks they might have a > contribution, are welcome. > > Mark > -- Luigi Paioro INAF - IASF Milano Via Bassini 15, I-20133 Milano, Italy Phone (+39) 02 23 699 470 Fax (+39) 02 26 660 17 Site http://www.iasf-milano.inaf.it/luigi/ From luigi at lambrate.inaf.it Tue Dec 2 05:34:44 2008 From: luigi at lambrate.inaf.it (Luigi Paioro) Date: Tue, 02 Dec 2008 14:34:44 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: <4935140A.9060903@simbad.u-strasbg.fr> References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> <4935140A.9060903@simbad.u-strasbg.fr> Message-ID: <49353974.7090105@lambrate.inaf.it> Dear Pierre, > In the future, if we want to extend SAMP for remote connections we could > invent a kind of gateway plugged on the hub and managing all the > required remote registrations, remote authentifications ... I wonder if > a dedicated SAMP client could do this job? since I personally use SAMP for remote connections, I had to deal with those topics you raised above. Instead of having a dedicated SAMP client I rather implemented some additional (optional) features to the SAMPy hub (valid only for the Standard Profile) like: 1) the possibility of running the hub (and the client) over a secure layer (HTTPS) allowing the setting (via command-line) of the key file and certificate file to use. It is also possible to set the "certification authority" certificates, which are used to validate certificates passed from the client end of the connection (if required). 2) the possibility of authenticating the client via Basic Authentication (which, in practice, is secure only if used over a secure socket), providing the hub with an authentication file (which is a Berkeley Database) containing the list of users with their passwords following a specific format and encryption rule. 3) since the mechanisms above do not exclude the SAMP basic security system, that is the exchange of the secret code written in the lock-file, it is possible to define via command-line a custom secret code, that, once conventionally fixed, can be used by the remote users/clients without the requirement of having access to the server .samp file. What I have done is not necessarily the best way to do things, but as far as I need, it works. The main problem I see in this design is that it is quite focused around the Standard Profile and perhaps not general enough. Maybe in the future we might find a better solution, but at least we already have a working implementation that could be used as the starting point for a future discussion. Luigi From boch at vizir.u-strasbg.fr Tue Dec 2 06:08:00 2008 From: boch at vizir.u-strasbg.fr (boch at vizir.u-strasbg.fr) Date: Tue, 02 Dec 2008 15:08:00 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: <20081202150800.v3gkd9t4rwq8sg40@astron.u-strasbg.fr> Mark, Thank you for this useful reply. Let me summarize what I understood from the 2 Bugzilla tickets you are referring to plus some tests of my own : It seems that VODesktop default behaviour is to use '127.0.0.1' as the default localhost, whereas JSAMP hub first tries to resolve it using InetAdress.getLocalHost()... (in both cases, this can be overriden using a dedicated system property). What would be the actual risks or troubles caused by using '127.0.0.1' as the default value for localhost in the SAMP XML-RPC url written in the lockfile ? In other words, which percentage of potential SAMP users might have a setup in which 127.0.0.1 is not the localhost ? Would these troubles be more annoying that the ones we have when connected to a network constantly going up and down (very common when giving a demonstration !), making connections to the hub unreliable because of the xml-rpc url being unreachable ? Thomas Quoting Mark Taylor : > On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > >> Hi Mark, >> >> I've been testing and playing with (J)SAMP the last days, and I had >> the following problem : >> >> - let's pretend I am connected to a wireless network whose DHCP >> server gives me hcp-131-176-166-130.esac.esa.int as hostname >> >> - if I launch a JSAMP hub, the lockfile will have the following line : >> samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ >> >> - now, if I disconnect from this network, and startup Aladin, it >> won't be able to connect to the hub because it won't be able to >> resolve the XML-RPC URL hostname. >> >> So, my question is : wouldn't it be safer to use the IP address >> instead of the hostname ? >> >> Subsidiary question : I noticed that sometimes, the Java method >> InetAddress.getLocalHost() throws an UnknownHostException (I use >> this method to set the callback URL of Aladin). In such a case, how >> safe is it to consider 127.0.0.1 to be the localhost IP address ? >> Though I am not a network expert at all, I feel this would do the >> right thing most of the time. Any opinion on that ? > > Thomas, > > good questions, not all of which I have good answers to. > I'm bouncing this onto the apps-samp list in case others have thoughts > or benefit from the discussion. > > First, this is an issue that we've come up against before in > AstroGrid in relation to the AG PLASTIC hub and the VODesktop/AR > XML-RPC server. The consensus seems to be that there is no best > way to do it - any single approach will fail under some network > setups (see the followup bugzilla tickets in the snippet below). > With that in mind, I've tried to cover all bases in JSAMP > by making this configurable. When JSAMP writes the hostname into > the hub lockfile, it uses the SampUtils.getLocalhost() utility method, > whose javadocs and source currently read like this: > > public static final String LOCALHOST_PROP = "samp.localhost"; > ... > > /** > * Returns a string denoting the local host to be used for communicating > * local server endpoints and so on. > * > *

This is normally obtained by calling > *

>       *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
>       * 
> * but this behaviour can be overridden by setting the > * {@link #LOCALHOST_PROP} system property to the string which should > * be returned instead. Sometimes local network issues make it > * advantageous to use some non-standard string such as "127.0.0.1". > * See, for instance, AstroGrid bugzilla tickets > * * >1799, > * * >2151. > * > * @return local host name > */ > public static String getLocalhost() { > String hostname = System.getProperty( LOCALHOST_PROP, "" ); > if ( hostname.length() == 0 ) { > try { > hostname = > InetAddress.getLocalHost().getCanonicalHostName(); > } > catch ( UnknownHostException e ) { > hostname = "127.0.0.1"; > } > } > return hostname; > } > > So, if you understand the problem you can fix it by running the hub > with the system property samp.localhost=131.176.166.130 or whatever > you reckon will work. > > This is a good start, but the trouble is people who don't understand > the problem (=most users) won't know what's up or how to fix it. > So there might be improvements to be made in advertising this > functionality or in choosing a safer default. Ideas from anyone who, > after reading the bugzilla tickets referenced above, thinks they might > have a contribution, are welcome. > > Mark > > -- > Mark Taylor Astronomical Programmer Physics, Bristol University, UK > m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ > From jfay at microsoft.com Tue Dec 2 09:12:57 2008 From: jfay at microsoft.com (Jonathan Fay) Date: Tue, 2 Dec 2008 09:12:57 -0800 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr>, Message-ID: Why not use the loopback address of 127.0.0.1? This works locally even if there is no network connection. If SAMP is supposed to be a local desktop tool, it should work on a airplane on a laptop with no netwrork, and on machiens at observatories with disconnected dialup connections. This also may cause problems with proxies trying to use the proxy server to talk between SAMP clients. Jonathan ________________________________________ From: Mark Taylor [m.b.taylor at bristol.ac.uk] Sent: Tuesday, December 02, 2008 1:37 AM To: boch at vizir.u-strasbg.fr Cc: apps-samp at ivoa.net Subject: Re: JSAMP hub and localhost hostname On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > Hi Mark, > > I've been testing and playing with (J)SAMP the last days, and I had the > following problem : > > - let's pretend I am connected to a wireless network whose DHCP server gives > me hcp-131-176-166-130.esac.esa.int as hostname > > - if I launch a JSAMP hub, the lockfile will have the following line : > samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ > > - now, if I disconnect from this network, and startup Aladin, it won't be > able to connect to the hub because it won't be able to resolve the XML-RPC > URL hostname. > > So, my question is : wouldn't it be safer to use the IP address instead of > the hostname ? > > Subsidiary question : I noticed that sometimes, the Java method > InetAddress.getLocalHost() throws an UnknownHostException (I use this method > to set the callback URL of Aladin). In such a case, how safe is it to > consider 127.0.0.1 to be the localhost IP address ? > Though I am not a network expert at all, I feel this would do the right thing > most of the time. Any opinion on that ? Thomas, good questions, not all of which I have good answers to. I'm bouncing this onto the apps-samp list in case others have thoughts or benefit from the discussion. First, this is an issue that we've come up against before in AstroGrid in relation to the AG PLASTIC hub and the VODesktop/AR XML-RPC server. The consensus seems to be that there is no best way to do it - any single approach will fail under some network setups (see the followup bugzilla tickets in the snippet below). With that in mind, I've tried to cover all bases in JSAMP by making this configurable. When JSAMP writes the hostname into the hub lockfile, it uses the SampUtils.getLocalhost() utility method, whose javadocs and source currently read like this: public static final String LOCALHOST_PROP = "samp.localhost"; ... /** * Returns a string denoting the local host to be used for communicating * local server endpoints and so on. * *

This is normally obtained by calling *

      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
      * 
* but this behaviour can be overridden by setting the * {@link #LOCALHOST_PROP} system property to the string which should * be returned instead. Sometimes local network issues make it * advantageous to use some non-standard string such as "127.0.0.1". * See, for instance, AstroGrid bugzilla tickets * 1799, * 2151. * * @return local host name */ public static String getLocalhost() { String hostname = System.getProperty( LOCALHOST_PROP, "" ); if ( hostname.length() == 0 ) { try { hostname = InetAddress.getLocalHost().getCanonicalHostName(); } catch ( UnknownHostException e ) { hostname = "127.0.0.1"; } } return hostname; } So, if you understand the problem you can fix it by running the hub with the system property samp.localhost=131.176.166.130 or whatever you reckon will work. This is a good start, but the trouble is people who don't understand the problem (=most users) won't know what's up or how to fix it. So there might be improvements to be made in advertising this functionality or in choosing a safer default. Ideas from anyone who, after reading the bugzilla tickets referenced above, thinks they might have a contribution, are welcome. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Tue Dec 9 08:33:15 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 9 Dec 2008 16:33:15 +0000 (GMT) Subject: JSAMP 0.3 Message-ID: Dear sampers, I have just released JSAMP 0.3. It can be found at the usual place, http://deployer.astrogrid.org/software/jsamp/index.html Details of the changes at this version are listed at: http://deployer.astrogrid.org/software/jsamp/history.html#Version_0_3 but briefly, this version implements the (PR) version 1.1 of the SAMP standard, and GUI and debugging features have been improved, including: - Hub and Client GUIs can now optionally show full and/or summarized details of every message exchanged. This can be very useful for debugging, as well as being nice to see what's going on. - There's a new little JComponent which just shows the icons of registered clients - useful and doesn't take up much screen space. - You can now optionally log to stdout every XML message, or an abbreviated RPC view of same, passed between clients and hub. - and more. Have fun. Any comments, queries, bug reports etc welcome. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Tue Dec 23 07:11:18 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 23 Dec 2008 15:11:18 +0000 (GMT) Subject: TOPCAT v3.4 Message-ID: Dear Reader, waiting under the Christmas tree for you is TOPCAT version 3.4. Full details in the version history as usual (http://www.starlink.ac.uk/topcat/sun253/versions.html) but the main items are: SAMP: TOPCAT now talks either SAMP or PLASTIC for inter-tool communication. Everything that used to work in PLASTIC now works in SAMP, but in SAMP mode the messaging is more robust and there are much better facilities for seeing the current state of messaging. Registry Access: TOPCAT now uses current versions of the VOResource and Registry Interface standards. It previously used a very out of date registry inerface and resource model. This affects mainly the Cone Search (but also semi-supported SIAP and Registry query) table load dialogues. Also: - Help can now be viewed in a web browser - Columns can be addressed by Utype as well as name, index and UCD - Bug fixes and other small enhancements More info and downloads from the usual place: http://www.starlink.ac.uk/topcat/ There is also an accompanying simultaneous release of STILTS (v2.0-1), but the STILTS release doesn't contain very much that's new. Merry Christmas one and all. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Tue Dec 23 07:11:18 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 23 Dec 2008 15:11:18 +0000 (GMT) Subject: TOPCAT v3.4 Message-ID: Dear Reader, waiting under the Christmas tree for you is TOPCAT version 3.4. Full details in the version history as usual (http://www.starlink.ac.uk/topcat/sun253/versions.html) but the main items are: SAMP: TOPCAT now talks either SAMP or PLASTIC for inter-tool communication. Everything that used to work in PLASTIC now works in SAMP, but in SAMP mode the messaging is more robust and there are much better facilities for seeing the current state of messaging. Registry Access: TOPCAT now uses current versions of the VOResource and Registry Interface standards. It previously used a very out of date registry inerface and resource model. This affects mainly the Cone Search (but also semi-supported SIAP and Registry query) table load dialogues. Also: - Help can now be viewed in a web browser - Columns can be addressed by Utype as well as name, index and UCD - Bug fixes and other small enhancements More info and downloads from the usual place: http://www.starlink.ac.uk/topcat/ There is also an accompanying simultaneous release of STILTS (v2.0-1), but the STILTS release doesn't contain very much that's new. Merry Christmas one and all. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Tue Dec 2 01:37:32 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 2 Dec 2008 09:37:32 +0000 (GMT) Subject: JSAMP hub and localhost hostname In-Reply-To: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > Hi Mark, > > I've been testing and playing with (J)SAMP the last days, and I had the > following problem : > > - let's pretend I am connected to a wireless network whose DHCP server gives > me hcp-131-176-166-130.esac.esa.int as hostname > > - if I launch a JSAMP hub, the lockfile will have the following line : > samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ > > - now, if I disconnect from this network, and startup Aladin, it won't be > able to connect to the hub because it won't be able to resolve the XML-RPC > URL hostname. > > So, my question is : wouldn't it be safer to use the IP address instead of > the hostname ? > > Subsidiary question : I noticed that sometimes, the Java method > InetAddress.getLocalHost() throws an UnknownHostException (I use this method > to set the callback URL of Aladin). In such a case, how safe is it to > consider 127.0.0.1 to be the localhost IP address ? > Though I am not a network expert at all, I feel this would do the right thing > most of the time. Any opinion on that ? Thomas, good questions, not all of which I have good answers to. I'm bouncing this onto the apps-samp list in case others have thoughts or benefit from the discussion. First, this is an issue that we've come up against before in AstroGrid in relation to the AG PLASTIC hub and the VODesktop/AR XML-RPC server. The consensus seems to be that there is no best way to do it - any single approach will fail under some network setups (see the followup bugzilla tickets in the snippet below). With that in mind, I've tried to cover all bases in JSAMP by making this configurable. When JSAMP writes the hostname into the hub lockfile, it uses the SampUtils.getLocalhost() utility method, whose javadocs and source currently read like this: public static final String LOCALHOST_PROP = "samp.localhost"; ... /** * Returns a string denoting the local host to be used for communicating * local server endpoints and so on. * *

This is normally obtained by calling *

      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
      * 
* but this behaviour can be overridden by setting the * {@link #LOCALHOST_PROP} system property to the string which should * be returned instead. Sometimes local network issues make it * advantageous to use some non-standard string such as "127.0.0.1". * See, for instance, AstroGrid bugzilla tickets * 1799, * 2151. * * @return local host name */ public static String getLocalhost() { String hostname = System.getProperty( LOCALHOST_PROP, "" ); if ( hostname.length() == 0 ) { try { hostname = InetAddress.getLocalHost().getCanonicalHostName(); } catch ( UnknownHostException e ) { hostname = "127.0.0.1"; } } return hostname; } So, if you understand the problem you can fix it by running the hub with the system property samp.localhost=131.176.166.130 or whatever you reckon will work. This is a good start, but the trouble is people who don't understand the problem (=most users) won't know what's up or how to fix it. So there might be improvements to be made in advertising this functionality or in choosing a safer default. Ideas from anyone who, after reading the bugzilla tickets referenced above, thinks they might have a contribution, are welcome. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From fernique at simbad.u-strasbg.fr Tue Dec 2 02:55:06 2008 From: fernique at simbad.u-strasbg.fr (Pierre Fernique) Date: Tue, 02 Dec 2008 11:55:06 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: <4935140A.9060903@simbad.u-strasbg.fr> Hi all, My experience with the GLU project: surprisingly, it is difficult to have a simple method for getting a correct full local hostname and it is worst if you want to be sure that this hostname is correctly registered in the DNS (correct alias for the IP). I strongly suggest to use 127.0.0.1 as PLASTIC/SAMP is presently really designed for local access. The 127.0.0.1 is managed at the IP stack level. So it is always responding even if you have several network cards or no card at all. It is constant (DHCP potential problem). And it should solve some potential firewall filter problems and potential security holes. In the future, if we want to extend SAMP for remote connections we could invent a kind of gateway plugged on the hub and managing all the required remote registrations, remote authentifications ... I wonder if a dedicated SAMP client could do this job? But in any case, by using 127.0.0.1, we will fix a lot of potential problems. Cheers, Pierre Mark Taylor a ?crit : > On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > >> Hi Mark, >> >> I've been testing and playing with (J)SAMP the last days, and I had >> the following problem : >> >> - let's pretend I am connected to a wireless network whose DHCP >> server gives me hcp-131-176-166-130.esac.esa.int as hostname >> >> - if I launch a JSAMP hub, the lockfile will have the following line : >> samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ >> >> - now, if I disconnect from this network, and startup Aladin, it >> won't be able to connect to the hub because it won't be able to >> resolve the XML-RPC URL hostname. >> >> So, my question is : wouldn't it be safer to use the IP address >> instead of the hostname ? >> >> Subsidiary question : I noticed that sometimes, the Java method >> InetAddress.getLocalHost() throws an UnknownHostException (I use this >> method to set the callback URL of Aladin). In such a case, how safe >> is it to consider 127.0.0.1 to be the localhost IP address ? >> Though I am not a network expert at all, I feel this would do the >> right thing most of the time. Any opinion on that ? > > Thomas, > > good questions, not all of which I have good answers to. I'm bouncing > this onto the apps-samp list in case others have thoughts > or benefit from the discussion. > > First, this is an issue that we've come up against before in AstroGrid > in relation to the AG PLASTIC hub and the VODesktop/AR > XML-RPC server. The consensus seems to be that there is no best way > to do it - any single approach will fail under some network > setups (see the followup bugzilla tickets in the snippet below). > With that in mind, I've tried to cover all bases in JSAMP > by making this configurable. When JSAMP writes the hostname into > the hub lockfile, it uses the SampUtils.getLocalhost() utility method, > whose javadocs and source currently read like this: > > public static final String LOCALHOST_PROP = "samp.localhost"; > ... > > /** > * Returns a string denoting the local host to be used for > communicating > * local server endpoints and so on. > * > *

This is normally obtained by calling > *

>      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
>      * 
> * but this behaviour can be overridden by setting the > * {@link #LOCALHOST_PROP} system property to the string which should > * be returned instead. Sometimes local network issues make it > * advantageous to use some non-standard string such as "127.0.0.1". > * See, for instance, AstroGrid bugzilla tickets > * * >1799, > * * >2151. > * > * @return local host name > */ > public static String getLocalhost() { > String hostname = System.getProperty( LOCALHOST_PROP, "" ); > if ( hostname.length() == 0 ) { > try { > hostname = > InetAddress.getLocalHost().getCanonicalHostName(); > } > catch ( UnknownHostException e ) { > hostname = "127.0.0.1"; > } > } > return hostname; > } > > So, if you understand the problem you can fix it by running the hub > with the system property samp.localhost=131.176.166.130 or whatever > you reckon will work. > > This is a good start, but the trouble is people who don't understand > the problem (=most users) won't know what's up or how to fix it. So > there might be improvements to be made in advertising this > functionality or in choosing a safer default. Ideas from anyone who, > after reading the bugzilla tickets referenced above, thinks they might > have a contribution, are welcome. > > Mark > From luigi at lambrate.inaf.it Tue Dec 2 03:10:38 2008 From: luigi at lambrate.inaf.it (Luigi Paioro) Date: Tue, 02 Dec 2008 12:10:38 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: <493517AE.2020604@lambrate.inaf.it> Thank you Mark for having posted this issue on the SAMP mailing list, it gives me an answer to an old problem Alastair Allan had with SAMPy on his laptop at home (maybe he remembers the problem), and I think the only reasonable solution to adopt is that that you indicated. I've just fixed SAMPy in order to try to get the host name using the standard socket library, but if it fails than, by default it is used 127.0.0.1. The next SAMPy release, that will come when the SAMP document v1.1 will be promoted to Recommendation, will include this feature. Luigi Mark Taylor ha scritto: > On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > >> Hi Mark, >> >> I've been testing and playing with (J)SAMP the last days, and I had >> the following problem : >> >> - let's pretend I am connected to a wireless network whose DHCP server >> gives me hcp-131-176-166-130.esac.esa.int as hostname >> >> - if I launch a JSAMP hub, the lockfile will have the following line : >> samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ >> >> - now, if I disconnect from this network, and startup Aladin, it won't >> be able to connect to the hub because it won't be able to resolve the >> XML-RPC URL hostname. >> >> So, my question is : wouldn't it be safer to use the IP address >> instead of the hostname ? >> >> Subsidiary question : I noticed that sometimes, the Java method >> InetAddress.getLocalHost() throws an UnknownHostException (I use this >> method to set the callback URL of Aladin). In such a case, how safe is >> it to consider 127.0.0.1 to be the localhost IP address ? >> Though I am not a network expert at all, I feel this would do the >> right thing most of the time. Any opinion on that ? > > Thomas, > > good questions, not all of which I have good answers to. I'm bouncing > this onto the apps-samp list in case others have thoughts > or benefit from the discussion. > > First, this is an issue that we've come up against before in AstroGrid > in relation to the AG PLASTIC hub and the VODesktop/AR > XML-RPC server. The consensus seems to be that there is no best way to > do it - any single approach will fail under some network > setups (see the followup bugzilla tickets in the snippet below). > With that in mind, I've tried to cover all bases in JSAMP > by making this configurable. When JSAMP writes the hostname into > the hub lockfile, it uses the SampUtils.getLocalhost() utility method, > whose javadocs and source currently read like this: > > public static final String LOCALHOST_PROP = "samp.localhost"; > ... > > /** > * Returns a string denoting the local host to be used for > communicating > * local server endpoints and so on. > * > *

This is normally obtained by calling > *

>      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
>      * 
> * but this behaviour can be overridden by setting the > * {@link #LOCALHOST_PROP} system property to the string which should > * be returned instead. Sometimes local network issues make it > * advantageous to use some non-standard string such as "127.0.0.1". > * See, for instance, AstroGrid bugzilla tickets > * * >1799, > * * >2151. > * > * @return local host name > */ > public static String getLocalhost() { > String hostname = System.getProperty( LOCALHOST_PROP, "" ); > if ( hostname.length() == 0 ) { > try { > hostname = > InetAddress.getLocalHost().getCanonicalHostName(); > } > catch ( UnknownHostException e ) { > hostname = "127.0.0.1"; > } > } > return hostname; > } > > So, if you understand the problem you can fix it by running the hub > with the system property samp.localhost=131.176.166.130 or whatever > you reckon will work. > > This is a good start, but the trouble is people who don't understand > the problem (=most users) won't know what's up or how to fix it. So > there might be improvements to be made in advertising this functionality > or in choosing a safer default. Ideas from anyone who, after reading > the bugzilla tickets referenced above, thinks they might have a > contribution, are welcome. > > Mark > -- Luigi Paioro INAF - IASF Milano Via Bassini 15, I-20133 Milano, Italy Phone (+39) 02 23 699 470 Fax (+39) 02 26 660 17 Site http://www.iasf-milano.inaf.it/luigi/ From luigi at lambrate.inaf.it Tue Dec 2 05:34:44 2008 From: luigi at lambrate.inaf.it (Luigi Paioro) Date: Tue, 02 Dec 2008 14:34:44 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: <4935140A.9060903@simbad.u-strasbg.fr> References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> <4935140A.9060903@simbad.u-strasbg.fr> Message-ID: <49353974.7090105@lambrate.inaf.it> Dear Pierre, > In the future, if we want to extend SAMP for remote connections we could > invent a kind of gateway plugged on the hub and managing all the > required remote registrations, remote authentifications ... I wonder if > a dedicated SAMP client could do this job? since I personally use SAMP for remote connections, I had to deal with those topics you raised above. Instead of having a dedicated SAMP client I rather implemented some additional (optional) features to the SAMPy hub (valid only for the Standard Profile) like: 1) the possibility of running the hub (and the client) over a secure layer (HTTPS) allowing the setting (via command-line) of the key file and certificate file to use. It is also possible to set the "certification authority" certificates, which are used to validate certificates passed from the client end of the connection (if required). 2) the possibility of authenticating the client via Basic Authentication (which, in practice, is secure only if used over a secure socket), providing the hub with an authentication file (which is a Berkeley Database) containing the list of users with their passwords following a specific format and encryption rule. 3) since the mechanisms above do not exclude the SAMP basic security system, that is the exchange of the secret code written in the lock-file, it is possible to define via command-line a custom secret code, that, once conventionally fixed, can be used by the remote users/clients without the requirement of having access to the server .samp file. What I have done is not necessarily the best way to do things, but as far as I need, it works. The main problem I see in this design is that it is quite focused around the Standard Profile and perhaps not general enough. Maybe in the future we might find a better solution, but at least we already have a working implementation that could be used as the starting point for a future discussion. Luigi From boch at vizir.u-strasbg.fr Tue Dec 2 06:08:00 2008 From: boch at vizir.u-strasbg.fr (boch at vizir.u-strasbg.fr) Date: Tue, 02 Dec 2008 15:08:00 +0100 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr> Message-ID: <20081202150800.v3gkd9t4rwq8sg40@astron.u-strasbg.fr> Mark, Thank you for this useful reply. Let me summarize what I understood from the 2 Bugzilla tickets you are referring to plus some tests of my own : It seems that VODesktop default behaviour is to use '127.0.0.1' as the default localhost, whereas JSAMP hub first tries to resolve it using InetAdress.getLocalHost()... (in both cases, this can be overriden using a dedicated system property). What would be the actual risks or troubles caused by using '127.0.0.1' as the default value for localhost in the SAMP XML-RPC url written in the lockfile ? In other words, which percentage of potential SAMP users might have a setup in which 127.0.0.1 is not the localhost ? Would these troubles be more annoying that the ones we have when connected to a network constantly going up and down (very common when giving a demonstration !), making connections to the hub unreliable because of the xml-rpc url being unreachable ? Thomas Quoting Mark Taylor : > On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > >> Hi Mark, >> >> I've been testing and playing with (J)SAMP the last days, and I had >> the following problem : >> >> - let's pretend I am connected to a wireless network whose DHCP >> server gives me hcp-131-176-166-130.esac.esa.int as hostname >> >> - if I launch a JSAMP hub, the lockfile will have the following line : >> samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ >> >> - now, if I disconnect from this network, and startup Aladin, it >> won't be able to connect to the hub because it won't be able to >> resolve the XML-RPC URL hostname. >> >> So, my question is : wouldn't it be safer to use the IP address >> instead of the hostname ? >> >> Subsidiary question : I noticed that sometimes, the Java method >> InetAddress.getLocalHost() throws an UnknownHostException (I use >> this method to set the callback URL of Aladin). In such a case, how >> safe is it to consider 127.0.0.1 to be the localhost IP address ? >> Though I am not a network expert at all, I feel this would do the >> right thing most of the time. Any opinion on that ? > > Thomas, > > good questions, not all of which I have good answers to. > I'm bouncing this onto the apps-samp list in case others have thoughts > or benefit from the discussion. > > First, this is an issue that we've come up against before in > AstroGrid in relation to the AG PLASTIC hub and the VODesktop/AR > XML-RPC server. The consensus seems to be that there is no best > way to do it - any single approach will fail under some network > setups (see the followup bugzilla tickets in the snippet below). > With that in mind, I've tried to cover all bases in JSAMP > by making this configurable. When JSAMP writes the hostname into > the hub lockfile, it uses the SampUtils.getLocalhost() utility method, > whose javadocs and source currently read like this: > > public static final String LOCALHOST_PROP = "samp.localhost"; > ... > > /** > * Returns a string denoting the local host to be used for communicating > * local server endpoints and so on. > * > *

This is normally obtained by calling > *

>       *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
>       * 
> * but this behaviour can be overridden by setting the > * {@link #LOCALHOST_PROP} system property to the string which should > * be returned instead. Sometimes local network issues make it > * advantageous to use some non-standard string such as "127.0.0.1". > * See, for instance, AstroGrid bugzilla tickets > * * >1799, > * * >2151. > * > * @return local host name > */ > public static String getLocalhost() { > String hostname = System.getProperty( LOCALHOST_PROP, "" ); > if ( hostname.length() == 0 ) { > try { > hostname = > InetAddress.getLocalHost().getCanonicalHostName(); > } > catch ( UnknownHostException e ) { > hostname = "127.0.0.1"; > } > } > return hostname; > } > > So, if you understand the problem you can fix it by running the hub > with the system property samp.localhost=131.176.166.130 or whatever > you reckon will work. > > This is a good start, but the trouble is people who don't understand > the problem (=most users) won't know what's up or how to fix it. > So there might be improvements to be made in advertising this > functionality or in choosing a safer default. Ideas from anyone who, > after reading the bugzilla tickets referenced above, thinks they might > have a contribution, are welcome. > > Mark > > -- > Mark Taylor Astronomical Programmer Physics, Bristol University, UK > m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ > From jfay at microsoft.com Tue Dec 2 09:12:57 2008 From: jfay at microsoft.com (Jonathan Fay) Date: Tue, 2 Dec 2008 09:12:57 -0800 Subject: JSAMP hub and localhost hostname In-Reply-To: References: <20081202100633.0hx90dbychq0w4g8@astron.u-strasbg.fr>, Message-ID: Why not use the loopback address of 127.0.0.1? This works locally even if there is no network connection. If SAMP is supposed to be a local desktop tool, it should work on a airplane on a laptop with no netwrork, and on machiens at observatories with disconnected dialup connections. This also may cause problems with proxies trying to use the proxy server to talk between SAMP clients. Jonathan ________________________________________ From: Mark Taylor [m.b.taylor at bristol.ac.uk] Sent: Tuesday, December 02, 2008 1:37 AM To: boch at vizir.u-strasbg.fr Cc: apps-samp at ivoa.net Subject: Re: JSAMP hub and localhost hostname On Tue, 2 Dec 2008, boch at vizir.u-strasbg.fr wrote: > Hi Mark, > > I've been testing and playing with (J)SAMP the last days, and I had the > following problem : > > - let's pretend I am connected to a wireless network whose DHCP server gives > me hcp-131-176-166-130.esac.esa.int as hostname > > - if I launch a JSAMP hub, the lockfile will have the following line : > samp.hub.xmlrpc.url=http://dhcp-131-176-166-130.esac.esa.int:55823/ > > - now, if I disconnect from this network, and startup Aladin, it won't be > able to connect to the hub because it won't be able to resolve the XML-RPC > URL hostname. > > So, my question is : wouldn't it be safer to use the IP address instead of > the hostname ? > > Subsidiary question : I noticed that sometimes, the Java method > InetAddress.getLocalHost() throws an UnknownHostException (I use this method > to set the callback URL of Aladin). In such a case, how safe is it to > consider 127.0.0.1 to be the localhost IP address ? > Though I am not a network expert at all, I feel this would do the right thing > most of the time. Any opinion on that ? Thomas, good questions, not all of which I have good answers to. I'm bouncing this onto the apps-samp list in case others have thoughts or benefit from the discussion. First, this is an issue that we've come up against before in AstroGrid in relation to the AG PLASTIC hub and the VODesktop/AR XML-RPC server. The consensus seems to be that there is no best way to do it - any single approach will fail under some network setups (see the followup bugzilla tickets in the snippet below). With that in mind, I've tried to cover all bases in JSAMP by making this configurable. When JSAMP writes the hostname into the hub lockfile, it uses the SampUtils.getLocalhost() utility method, whose javadocs and source currently read like this: public static final String LOCALHOST_PROP = "samp.localhost"; ... /** * Returns a string denoting the local host to be used for communicating * local server endpoints and so on. * *

This is normally obtained by calling *

      *    java.net.InetAddress.getLocalHost().getCanonicalHostName()
      * 
* but this behaviour can be overridden by setting the * {@link #LOCALHOST_PROP} system property to the string which should * be returned instead. Sometimes local network issues make it * advantageous to use some non-standard string such as "127.0.0.1". * See, for instance, AstroGrid bugzilla tickets * 1799, * 2151. * * @return local host name */ public static String getLocalhost() { String hostname = System.getProperty( LOCALHOST_PROP, "" ); if ( hostname.length() == 0 ) { try { hostname = InetAddress.getLocalHost().getCanonicalHostName(); } catch ( UnknownHostException e ) { hostname = "127.0.0.1"; } } return hostname; } So, if you understand the problem you can fix it by running the hub with the system property samp.localhost=131.176.166.130 or whatever you reckon will work. This is a good start, but the trouble is people who don't understand the problem (=most users) won't know what's up or how to fix it. So there might be improvements to be made in advertising this functionality or in choosing a safer default. Ideas from anyone who, after reading the bugzilla tickets referenced above, thinks they might have a contribution, are welcome. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Tue Dec 9 08:33:15 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 9 Dec 2008 16:33:15 +0000 (GMT) Subject: JSAMP 0.3 Message-ID: Dear sampers, I have just released JSAMP 0.3. It can be found at the usual place, http://deployer.astrogrid.org/software/jsamp/index.html Details of the changes at this version are listed at: http://deployer.astrogrid.org/software/jsamp/history.html#Version_0_3 but briefly, this version implements the (PR) version 1.1 of the SAMP standard, and GUI and debugging features have been improved, including: - Hub and Client GUIs can now optionally show full and/or summarized details of every message exchanged. This can be very useful for debugging, as well as being nice to see what's going on. - There's a new little JComponent which just shows the icons of registered clients - useful and doesn't take up much screen space. - You can now optionally log to stdout every XML message, or an abbreviated RPC view of same, passed between clients and hub. - and more. Have fun. Any comments, queries, bug reports etc welcome. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Tue Dec 23 07:11:18 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 23 Dec 2008 15:11:18 +0000 (GMT) Subject: TOPCAT v3.4 Message-ID: Dear Reader, waiting under the Christmas tree for you is TOPCAT version 3.4. Full details in the version history as usual (http://www.starlink.ac.uk/topcat/sun253/versions.html) but the main items are: SAMP: TOPCAT now talks either SAMP or PLASTIC for inter-tool communication. Everything that used to work in PLASTIC now works in SAMP, but in SAMP mode the messaging is more robust and there are much better facilities for seeing the current state of messaging. Registry Access: TOPCAT now uses current versions of the VOResource and Registry Interface standards. It previously used a very out of date registry inerface and resource model. This affects mainly the Cone Search (but also semi-supported SIAP and Registry query) table load dialogues. Also: - Help can now be viewed in a web browser - Columns can be addressed by Utype as well as name, index and UCD - Bug fixes and other small enhancements More info and downloads from the usual place: http://www.starlink.ac.uk/topcat/ There is also an accompanying simultaneous release of STILTS (v2.0-1), but the STILTS release doesn't contain very much that's new. Merry Christmas one and all. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Tue Dec 23 07:11:18 2008 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 23 Dec 2008 15:11:18 +0000 (GMT) Subject: TOPCAT v3.4 Message-ID: Dear Reader, waiting under the Christmas tree for you is TOPCAT version 3.4. Full details in the version history as usual (http://www.starlink.ac.uk/topcat/sun253/versions.html) but the main items are: SAMP: TOPCAT now talks either SAMP or PLASTIC for inter-tool communication. Everything that used to work in PLASTIC now works in SAMP, but in SAMP mode the messaging is more robust and there are much better facilities for seeing the current state of messaging. Registry Access: TOPCAT now uses current versions of the VOResource and Registry Interface standards. It previously used a very out of date registry inerface and resource model. This affects mainly the Cone Search (but also semi-supported SIAP and Registry query) table load dialogues. Also: - Help can now be viewed in a web browser - Columns can be addressed by Utype as well as name, index and UCD - Bug fixes and other small enhancements More info and downloads from the usual place: http://www.starlink.ac.uk/topcat/ There is also an accompanying simultaneous release of STILTS (v2.0-1), but the STILTS release doesn't contain very much that's new. Merry Christmas one and all. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/