<div><div dir="auto">Hi Mark </div><div dir="auto">and greetings from Chile where we’ve had nasty weather at the telescope all week...</div></div><div dir="auto"><br></div><div dir="auto">To answer your first question, I would say that installing a browser extension is a very minor operation from the user’s point of view. You can also automatically redirect from a web page to the extension installation. And I would be absolutely happy to do so despite being very cautious about installing stuff in the browser. Many people would agree with me here. </div><div dir="auto"><br></div><div dir="auto">Regarding your second concern, despite I’m not a specialist in the topic, I would say that the APIs for extension development should be pretty similar at least in Firefox and Chrome because lots of extensions exist for both browsers (even something developed by the individuals) so this suggests that maintaining the code for the two in parallel is not so hard. Not sure about safari. </div><div dir="auto"><br></div><div dir="auto">With best regards,</div><div dir="auto">Igor</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 14, 2019 at 9:38 AM Mark Taylor <<a href="mailto:M.B.Taylor@bristol.ac.uk">M.B.Taylor@bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Hugo,<br>
<br>
thanks for the input. I didn't go through all the possibilities<br>
in my talk, but yes a browser plugin of some sort might be able to<br>
solve the problem (and historically I think that some SAMP browser<br>
plugins existed before the Web Profile was introduced as an alternative<br>
solution to that problem, but I don't think they got much beyond<br>
the experimental stage). A couple of other people mentioned this<br>
at the meeting too.<br>
<br>
I have two main reservations about this option. First, will users<br>
actually install a browser extension? And second, the amount of<br>
work involved in writing and maintaining the extension code for<br>
multiple versions of multiple browsers. I don't have much grasp<br>
of how big a drawback either of those things is though.<br>
If anybody wants to experiment with implementation and report back,<br>
that would be great.<br>
<br>
Mark<br>
<br>
<br>
On Mon, 14 Oct 2019, Hugo Buddelmeijer wrote:<br>
<br>
> Hi all,<br>
> <br>
> Would a SAMP browser plugin be a solution to the https problem?<br>
> <br>
> That is, users install a samp-plugin, the websites connect to the plugin,<br>
> and the plugin connects to the samp-hub. This seems possible:<br>
> <a href="https://developer.chrome.com/extensions/nativeMessaging" rel="noreferrer" target="_blank">https://developer.chrome.com/extensions/nativeMessaging</a><br>
> <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging" rel="noreferrer" target="_blank">https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging</a><br>
> <br>
> Maybe it would be feasible to have this browser plugin to be effectively<br>
> another SAMP hub (that talks to the desktop hub); that is, adding a new<br>
> browser-plugin profile to standard. That way anyone could make a compliant<br>
> plugin so we would not be at the merci of this hypothetical plugin author.<br>
> <br>
> There are only a few browsers (chrome, firefox, safari), so it might be<br>
> less work than the relay-solution.<br>
> <br>
> My experience with browser plugins is very limited (a single experiment<br>
> years ago), so maybe it is not as simple. And maybe installing<br>
> yet-another-browser-plugin for just a single use case is too much overhead<br>
> for some people.<br>
> <br>
> Any thoughts?<br>
> <br>
> Hugo<br>
> <br>
> <br>
> <br>
> On Thu, 22 Aug 2019 at 15:05, Mark Taylor <<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>> wrote:<br>
> <br>
> > Dear SAMP users,<br>
> ><br>
> > the problem of Web SAMP and HTTPS has been under discussion<br>
> > for a while now - basically the Web Profile works fine with HTTP<br>
> > but won't work from pages served using HTTPS. A possible HTTPS-capable<br>
> > profile has been prototyped, but it's pretty nasty. There is much<br>
> > more information on the topic here:<br>
> ><br>
> > <a href="http://andromeda.star.bristol.ac.uk/websamp/" rel="noreferrer" target="_blank">http://andromeda.star.bristol.ac.uk/websamp/</a><br>
> ><br>
> > As an alternative to the HTTPS profile, I'm thinking about more<br>
> > lightweight workarounds. One is just to provide a simple helper<br>
> > application that takes a suitable filename on the command line<br>
> > (VOTable table or FITS image) and sends it to a running SAMP<br>
> > client. Such an application could be associated in the<br>
> > browser with suitable MIME types (application/x-votable+xml,<br>
> > image/fits), or you could just choose it when the browser<br>
> > asks you what application you want to open a downloaded file with.<br>
> ><br>
> > This is much less flexible than allowing the web page (web application)<br>
> > to interact with the SAMP hub itself, which is what you can do<br>
> > with SAMP+Web Profile. However, in practice, nearly(?) all Web SAMP<br>
> > pages that I'm aware of just use Web SAMP to allow the user to<br>
> > send a samp.load.votable or image.load.fits message, and that's<br>
> > done nearly as well by the helper application. It works with<br>
> > rather than against normal browser operations, which makes it<br>
> > much less painful to implement than the HTTPS profile;<br>
> > it works equally with HTTPS or HTTP, and no additional<br>
> > infrastructure is required. The main downside is that the user has<br>
> > to configure it somehow (install script, tell browser to use it<br>
> > to handle relevant files).<br>
> ><br>
> > I have written such a helper application, and I'd be interested<br>
> > to know if anyone wants to try it out: especially data providers<br>
> > who are using HTTPS and want to allow users to load tables/images<br>
> > using SAMP. Would this be an acceptable solution?<br>
> ><br>
> > You can find the application here:<br>
> ><br>
> > <a href="http://andromeda.star.bris.ac.uk/websamp/sampload.jar" rel="noreferrer" target="_blank">http://andromeda.star.bris.ac.uk/websamp/sampload.jar</a><br>
> ><br>
> > If you run, e.g. "java -jar sampload.jar /tmp/tmpfile.vot"<br>
> > then it will pop up a window asking which VOTable-capable<br>
> > SAMP client you want to send tmpfile.vot to.<br>
> > (It works out what kind of file it is by looking at the content).<br>
> ><br>
> > Unless your OS/browser can execute jar files directly, to use it with<br>
> > a browser you'll need to accompany it with a small shell script or<br>
> > equivalent like<br>
> ><br>
> > #!/bin/sh<br>
> > java -jar /path/to/sampload.jar "$@"<br>
> ><br>
> > Any feedback, comments, ideas welcome.<br>
> ><br>
> > Mark<br>
> ><br>
> > --<br>
> > Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
> > <a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
> ><br>
> <br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
<br>
</blockquote></div></div>