Version 0.2

The XML-RPC and Standard Profile-related parts of the library have
been reorganised somewhat.
A new package
org.astrogrid.samp.xmlrpc
ant its descendants now hold all
the code which relates specifically to XML-RPC communications and
the SAMP Standard Profile; the code in the other packages is
profile-agnostic and handles only transport-independent aspects
of the protocol.
The xmlrpc package itself defines a pluggable
interface for providing XML-RPC client and server functionality;
two implementations are also provided, in the packages
xmlrpc.apache
and
xmlrpc.internal.
The Apache one is basically what was there in previous versions;
the internal one is completely freestanding, and if this is used
the Apache XML-RPC library is not required for operation.

GUI functionality added

There are more classes in the
org.astrogrid.samp.gui package
to facilitate high-level use of SAMP within GUI applications.
ConnectorGui
provides Actions suitable for insertion in a general SAMP control menu,
and
SendActionManager
provides menus and Actions for sending particular messages.

Version 0.3

There is now an option for both hub and client GUI to keep track
of and display messages which have been sent.
HubRunner and HubMonitor GUIs by default now have tabs
showing messages sent/received and their current status -
see GUI Features section for some
screenshots.
To see this in action, start the HubRunner in
(default) msg-gui mode and then run
HubTester. Or just use the hub with your own
SAMP clients.
Note that this functionality incurs some overhead - if not used
no such overhead is incurred.

A new small GUI component is available which just shows the icons for
all registered clients (like what used to appear in the bottom right
corner of VODesktop windows).

Facilities have been added for full logging of all XML or RPC
communications in the hub or clients.
See new xml-log and rpc-log options
to -xmlrpc flags of command-line tools, and classes
org.astrogrid.samp.xmlrpc.internal.*LoggingInternal*.

Replace DefaultSendActionManager with other,
more capable, SendActionManager subclasses.
This makes it easy to handle the results from messages which
have been sent, for instance by passing the information to the
user graphically or in other ways.

HubMonitor tool can now subscribe to messages other than
administrative ones, like Snooper.

MessageSender tool now pretty-prints response(s).

Backwards Compatibility:

There have been a number of changes since release 0.2 which are
backwardly incompatible, so that source code using earlier versions
of JSAMP will need to be adjusted. GUI-related functionality is
most affected. This is because I'm still
designing it, and some changes were required to accommodate new
features etc; sorry. I hope that there will be fewer backwardly
incompatible changes in the future as the library matures - but I'm
not offering any guarantees just yet.
Some of the more obvious changes are as follows:

New class gui.GuiHubConnector now contains the
Swing-related functionality which was previously in
(its superclass) client.HubConnector, and also
all the functionality from the now removed class
gui.ConnectorGui.

HubRunner and ConnectorGui APIs modified
to permit use of various different hub implementations
(with different graphical characteristics -
see HubMode).

If there are things which used to work in a previous version and you
can't see how to do it now, please contact me and I'll advise how
to update.

Bugfixes:

Fixed server error which sometimes resulted in failed reads,
especially for long messages.

Fixed error in handling CalcStorm -xmlrpc flag.

Other:

Change return values of callAll and
notifyAll hub methods as per agreed modifications to
the standard at version 1.1.
Affects hub and client API, implementation and test suite.

Version 0.3-1

Add GuiHubConnector.createRegisterOrHubAction method,
which registers if it can, else offers the user to start a hub.
This may be the only button you need.

Internal HTTP server now tolerates LF as well as the correct CRLF as
HTTP request header line terminators, as recommended by HTTP 1.1
(RFC2616).

Add convenience methods call and callAll
to HubConnector - these allow you to make asynchronous
calls so that the results are delivered as callbacks to
supplied objects without having to worry about registering
handlers and matching tags.

Moved HTTP server implementation used by internal XML-RPC
implementation into its own package, samp.httpd.
Also added some utility classes in that package to facilitate
serving dynamic resources and resources from the classpath.
This is because having a simple self-contained HTTP server
may be useful for client implementations doing SAMP-like things
other than strictly communicating with the hub.

ResultHandler and LogResultHandler classes
moved from package gui to client.

Version 1.0

Though this version is numbered 1.0, it's not a giant leap ahead
of the previous one (0.3-1). However, this is the first release
since SAMP became an IVOA Recommendation,
and this toolkit is believed to be fully compliant with that standard.
The intention is that backwardly incompatible changes will be kept
to a minimum following this release.

New functionality:

New Bridge client added.
This is a significant bit of infrastructure which allows clients
on different hubs to interoperate.

The help message now reports relevant system properties as well as
other help info.

Changes to behaviour
(note some of these may have backward compatibility issues):

The default hostname for HTTP server etc
(SampUtils.getLocalHost())
is now "127.0.0.1", not the DNS name; in certain network environments this
works better than the alternatives, though it's less good for
inter-machine communications.
This default can be altered by setting the samp.hostname
system property; it has two new special values "[hostname]" and
"[hostnumber]".

Icon URLs declared by test clients etc now use internal server references
rather than links to external static resources. This means icons
are not dependent on network availability.

Remove warning if permission change on .samp file to owner-only read fails.
This permission change is probably not possible on Windows-like OSes
(unless anyone can tell me different),
and the warning causes confusion.

System property samp.localhost renamed to
jsamp.localhost
(the old name is still recognised for backward compatibility).

Withdraw -xmlrpc flag from command-line tools;
the jsamp.xmlrpc.impl system property should be used
instead.

Standard version is now reported as v1.11 REC 2009-04-21.

API Changes
(note some of these may have backward compatibility issues):

Added DefaultClientProfile class;
this is now the recommended way of getting a general purpose ClientProfile
object (rather than using StandardClientProfile.getInstance().
Using this will aid pluggability (ability to use with non-standard
profiles in the future).

Added UtilServer class; this can help to reduce the number
of HTTP servers run by a JSAMP application,
and provides convenience methods for exporting
local (e.g. file: or classpath) URLs.

Added getHubClient and disconnect methods to
BasicHubService; you can now use the hub object to forcibly
disconnect clients.

StandardClientProfile now has overridable getLockInfo
method for better customisability.

Added parseValue utility method to SampUtils
class.

Added new method HubConnector.connectionChanged.

InternalServerFactory now returns a server which can be safely
reused.

Class LockInfo moved from org.astrogrid.samp
package to org.astrogrid.samp.xmlrpc,
which is where it should have been.

Bugfixes:

Missing jsamp.version file now included in source
zip archive.

Fixed error reporting bug in messagesender tool.

Version 1.1

The environment variable SAMP_HUB can now be used to specify a
non-default lockfile location for clients and hub to use with the
Standard Profile. This usage is expected to be part of the next
version of the SAMP standard (SAMP 1.2, in WD at time of writing).
See the documentation for the
StandardClientProfile
class for details, and
DefaultClientProfile
for a JSAMP-specific extension to this mechanism.
The non-standard
jsamp.lockfile and jsamp.profile
system properties which did the same job in a non-standard way
have been withdrawn.
This has some backwardly incompatible consequences:

SampUtils.getLockFile() method withdrawn;
use StandardClientProfile.getLockUrl() instead.
If you want to find out if a hub is running, instead of
SampUtils.getLockFile().exists(), use
DefaultClientProfile.getProfile().isHubRunning().

Where possible, if the hub is running in GUI mode it will now install
itself as an icon in the "system tray" rather than posting the
window directly; a popup menu associated with the tray icon allows
window display and hub shutdown. If the platform does not provide
system tray functionality, it will revert to the previous behaviour of
posting the window directly.
System tray functionality is available only when running under
Java 1.6 or later, and only when using a suitable display manager.

Added -httplock flag to hubrunner, which allows publication
of lockfile by HTTP for use by non-localhost clients.

Usability:

Invoking JSamp class (e.g. "java -jar jsamp.jar")
with no arguments
now starts the hub rather than just printing a usage message.

ClientProfile interface has new method isHubRunning.
This is more general (and easier to use) than testing something like
StandardClientProfile.getLockFile().exists().

Version 1.2

The two main changes at this release are generalisation of the
hub running framework to allow multiple profiles to run interfacing to
the same hub simultaneously, and implementation of the experimental
Web Profile. The former was motivated by the latter (though should really
have been present from the start). This work was suggested by
Jonathan Fay and financially supported by Microsoft Research,
whose support is gratefully acknowledged. There are also
a number of bug fixes and minor enhancements.

Hub framework:

The org.astrogrid.samp.hub.HubRunner
class has been deprecated in favour of the new class
org.astrogrid.samp.hub.Hub.
This can be used from the command line or programmatically to start a hub,
and it can run zero or more profiles, defined by the new
HubProfile
interface, simultaneously. HubProfile implementations are provided for
the Standard Profile and the Web Profile, and you can plug in your own
at runtime. This class is now the Main-Class defined in the jar file's
Manifest, so invoking (e.g. clicking or java -jar) the jsamp-*.jar file
will now invoke this class. Documentation of the command-line usage
is on the Command-line Tools page.
By default only the Standard Profile is run, so simply invoking the
jar file will have much the same behaviour as it did in previous
versions, that is starting a Standard Profile-only hub.
Which profiles are run can be influenced in various ways,
including by defining the
jsamp.hub.profiles
system property.

A new "facade" mode of hub operation has been introduced, which
allows tunnelling from one hub profile to another (mostly of interest
to hub profile implementors).

There have been a number of other backwardly incompatible changes to
the hub implementation classes:
Most of the HubService interface has been replaced using
HubConnection and Receiver has been replaced with
CallableClient, reducing amount and duplication of code,
and some assumptions specific to the Standard Profile have been
removed from the interfaces of hub classes which are properly
profile-independent.
These changes are not believed likely to affect
anybody who is not writing hub implementation code.

Web Profile:

This release also includes client and hub implementations of the
experimental Web Profile.
Implementation is in the new package
org.astrogrid.samp.web.
Note that this profile is still under discussion and details of the
definition may change in the future.

Fixed some concurrency bugs to do with handler lists in
HubConnector, HttpServer,
InternalServer and ApacheServer
(thanks to Laurent Bourgès).

Fixed, I think, threading issues that occasionally prevented hub
forced shutdown notifications getting to some clients.
It is possible this fix will have knock-on performance or other effects,
especially in the presence of badly-behaved clients -
please report if you notice problems.
Thanks (again) to Laurent Borgès for extensive help with this.

Fixed a bug related to output capture when an external hub is started.

Some additional system properties are now propagated when starting an
external hub.

Window positioning now follows platform norms by default rather than the
java policy of placement at (0,0).
Specifically: the java.awt.Window.locationByPlatform
system property is set, if it does not already have an explicit value,
in the JSamp class.

AbstractMessageHandler has a new method createResponse
which may be overridden for more flexibility.

External hub start action is disabled in JNLP context, since
it won't work.