ask for a new application message in samp

[Mark Taylor]

Incidentally, TOPCAT can be used without modification to generate
messages like this e.g. for purposes of experiment.

The "SAMP Message" activation action can be set up to pass ASCII MOC 
text and other column values to listeners:

   http://www.starlink.ac.uk/topcat/sun253/SendCustomActivationType.html

(you need to use the Actions->Add Action menu if the SAMP Message
option doesn't show up by default).

Then when you click on a row, the MOC gets sent to Aladin or
whoever is subscribed to the coverage.load.ascii.moc MType.

I attach a screenshot of what this might look like.

Mark

On Thu, 21 May 2026, Thomas Boch wrote:

> Hi Mark and Pierre,
> 
> I also support this addition. Once this MType is defined (name and
> parameters), we (the Aladin team) can shortly add support for it to Aladin
> Desktop and Aladin Lite for testing further.
> 
> 
> Thomas
> 
> Le 21/05/2026 à 14:31, Mark Taylor via apps a écrit :
> > Hi Pierre,
> > 
> > I'm replying to this message as de facto SAMP buff and an author/editor
> > of the SAMP standard, but opinions of other Apps WG members are of
> > course welcome.
> > 
> > The general approach in agreeing on MTypes is to avoid multiple ways
> > to communicate the same thing, to avoid the situation where clients
> > have to support many different serializations to send and receive
> > the same type of data.  So for instance it's recommended where
> > possible to stick to table.load.votable when exchanging tables -
> > though in fact there are clients that use table.load.{fits,cdf,csv} etc.
> > The documentation of coverage.load.moc.fits for this reason says
> > "the introduction of alternative MOC load MTypes is not encouraged"
> > (https://wiki.ivoa.net/twiki/bin/view/IVOA/SampMTypes#coverage.load.moc.fits)
> > 
> > However in my personal opinion coverage.load.moc.ascii would be a
> > reasonable addition to the loosely-agreed list of well-known MTypes.
> > That's partly because an ASCII-serialized MOC is not expected to
> > be very large, so exchanging it in-line within the SAMP message itself
> > is feasible; this is different from coverage.load.moc.fits,
> > which references the MOC by URL.
> > 
> > If you want to pursue this I'd suggest to prototype its use in
> > at least one sending and one receiving client and if it seems
> > to work as expected then report back to the Apps WG (e.g. on this list);
> > if nobody objects I think it could then be added to the list at
> > https://wiki.ivoa.net/twiki/bin/view/IVOA/SampMTypes
> > 
> > Mark
> > 
> > On Thu, 21 May 2026, Pierre Le Sidaner via apps wrote:
> > 
> > > To Apps
> > > 
> > > as in the registry EPN-TAP use coverage in ascii MOC format, and we want
> > > to
> > > send the coverage to different clients
> > > The available MType is coverage.load.moc.fits
> > > Could it be possible to have something like coverage.load.moc.ascii or
> > > whatever over denomination that correspond to ascii MOC
> > > 
> > > Regards
> > > Pierre
> > > 
> > > 
> > --
> > Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> > m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/
> > 
> > 
> > 
> > 
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samp-moc.png
Type: image/png
Size: 46408 bytes
Desc: 
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20260521/0f052e98/attachment-0001.png>