UrlOpen needs Arexx Support

AmigaOS users can make feature requests in this forum.
User avatar
djrikki
Posts: 138
Joined: Fri Jun 17, 2011 10:21 pm
Location: Grimsby, Lincolnshire, UK
Contact:

UrlOpen needs Arexx Support

Post by djrikki »

Hello,

As a Hollywood developer I quickly found out that I was made to pick the third-party software OpenURL over the AmigaOS standard URLOpen plain and simply because it has Arexx Support.

If the user's browser of choice is already open in the background and the end-user opens a link outside of the browser - passing through URLOpen it will instead (when possible) open a second instance of the user's browser of choice instead of simply opening a new tab/window within the already open browser.

Subsequently standard preferences for URLOpen should be pre-loaded in the distribution/update with the correct Arexx syntax for all the popular browser choices.
chris
Posts: 562
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: UrlOpen needs Arexx Support

Post by chris »

djrikki wrote:Hello,

As a Hollywood developer I quickly found out that I was made to pick the third-party software OpenURL over the AmigaOS standard URLOpen plain and simply because it has Arexx Support.

If the user's browser of choice is already open in the background and the end-user opens a link outside of the browser - passing through URLOpen it will instead (when possible) open a second instance of the user's browser of choice instead of simply opening a new tab/window within the already open browser.

Subsequently standard preferences for URLOpen should be pre-loaded in the distribution/update with the correct Arexx syntax for all the popular browser choices.
You can emulate the "use ARexx if the browser is already open" functionality by writing a script which is called by URLOpen (launch-handler) rather than called the executable directly. Andy Broad wrote an example up somewhere.

I agree this should be present by default.
kas1e
Beta Tester
Beta Tester
Posts: 542
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: UrlOpen needs Arexx Support

Post by kas1e »

There is already BZ #8022 about adding AREXX support to URLOpen. I add link on that thread to it, so it will be visibly that there is still needs for.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: UrlOpen needs Arexx Support

Post by colinw »

Arexx support will not be added to l:launch-handler or c:URLOpen, at least not by me.
Arexx is basically legacy software and parts of it are still in 68K assembly language and will have to stay
that way, as far as I understand, it is not possible to do anything about this due to some sort of issue
with the licence, whether this situation has changed in recent history, is unknown by me.

Also, just like any other application running on AmigaOS, applications such as web browsers and
email clients, etc... must also be able to operate properly via the shell commandline interface and they
must support all required features within the commandline arguments, this must also include being
able to detect multiple instances of the same application being launched, if this were to cause issues,
and therefore it should take appropriate action if this situation were to occur.

Such action for example, using a web browser, would be to not start another GUI instance of the
application, but instead open a new window or tab on the existing instance and display the supplied URL.

This requirement may be best implimented by using a small "loader" executable that messages/runs
an existing instance of the application. Such a small "loader" style executable should also be used
when the main application takes longer than two full seconds for the GUI to appear and must render
a splash window indicating the loading status of the main application so the user receives adequate feedback.

The commandline format used for such applications should be declared in the help prompt using the
normal IDOS->ReadArgs() function template. As each application has its own setup line in the launch-handler
URL configuration, the format used is up to the author of the software, however, it would be wise to use formats
similar to other software of its type to avoid confusion.

This is all that is required for an application to successfully use the supplied launch-handler and URLOpen commands.
Last edited by colinw on Sat Jun 22, 2013 10:28 pm, edited 2 times in total.
User avatar
ChrisH
Beta Tester
Beta Tester
Posts: 920
Joined: Mon Dec 20, 2010 9:09 pm
Contact:

Re: UrlOpen needs Arexx Support

Post by ChrisH »

@colinw
It seems that you are advocating a different trade-off for URLOpen than what OpenURL chose. Specifically, you want to keep URLOpen as simple as possible (both implementation AND user configuration), such that there is only a single command for each program. The trade-off is a slight increase in complexity of programs used by URLOpen, but this is really just making such programs work correctly (i.e. support being run more than once from the Shell, without the caller having to specifically check for an ARexx port). In the case of very large programs (e.g. a web browser), a second trade-off is that it needs a second small program acting as a proxy, so as to avoid a large loading delay when opening a second URL.

I am inclined to say that you chose the right trade-off... BUT I humbly suggest your solution is still incomplete regarding two situations:
1. Old programs, which won't get updated to work correctly for some reason (e.g. the program is no-longer developed).
2. Multi-platform programs, where OpenURL is the only way on those other platforms, and the developer either doesn't want to introduce additional code just for OS4, or else simply doesn't understand that OS4 must be handled differently.

The solution to both these problems is to provide an extra Shell program with URLOpen, which will handle the ARexx stuff. I imagine it having a template something like this:

ARexxProxy PortName=Port/A,ARexxMessage=Msg/A,ShellCommand=Cmd/F/K

If PortName exists then it sends the ARexxMessage, otherwise it executes ShellCommand.

Additional benefits of this program would be:
3. Authors of big programs could use this if they didn't want to write a special launcher. It could even have an optional splash-window (image) parameter for such cases. (I made ShellCommand have /K so that such parameters could be added later without causing a problem.)
4. No need for users to wait for programs to be updated to properly support URLOpen.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: UrlOpen needs Arexx Support

Post by colinw »

ChrisH wrote:@colinw
...
I am inclined to say that you chose the right trade-off... BUT I humbly suggest your solution is still incomplete regarding two situations:
1. Old programs, which won't get updated to work correctly for some reason (e.g. the program is no-longer developed).
2. Multi-platform programs, where OpenURL is the only way on those other platforms, and the developer either doesn't want to introduce additional code just for OS4, or else simply doesn't understand that OS4 must be handled differently.

The solution to both these problems is to provide an extra Shell program with URLOpen, which will handle the ARexx stuff.
1.
Is not really an issue, most of the applications in use today are still being worked on, and if they are not, it would take me
under 15 minutes to write a small CLI program to handle whatever the existing communications interface happens to be.

2.
Is not really valid, as the absolutely MOST compatible interface for all AmigaOS applications, on any particular platform,
is to be capable of being started from WB or CLI, the latter method is all it takes to support URLOpen / launch-handler.
So, if an application doesn't even have rudimentary CLI commandline support, it's not really an AmigaOS compatible app.

The best thing you could do is simply try them out in a shell and if they don't have the required functionality to work
via the CLI interface, ask the author to provide the feature/s required via the IDOS->ReadArgs() function template.
kas1e
Beta Tester
Beta Tester
Posts: 542
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: UrlOpen needs Arexx Support

Post by kas1e »

@colinw
ask the author to provide the feature/s required via the IDOS->ReadArgs() function template.
In some cases its just not possible, and users will live for years with half-working prog .. Not saying that even if program still in develop it can be low priority at moment and all usual mambo-jambo, while if .. then :)
User avatar
ChrisH
Beta Tester
Beta Tester
Posts: 920
Joined: Mon Dec 20, 2010 9:09 pm
Contact:

Re: UrlOpen needs Arexx Support

Post by ChrisH »

colinw wrote:it would take me under 15 minutes to write a small CLI program to handle whatever the existing communications interface happens to be.
That might be true in principle, but in practice we are still here 1-2 years later (or possibly longer) with both Timberwolf & MUI-OWB not working correctly with URLOpen. Not to mention RA-OWB, probably IBrowse, and possibly even NetSurf (I can't check at the moment).

If OS4 came with a standard program like I suggested, then all OS4 users would benefit immediately, versus potentially waiting years more for the developers to fix their respective programs (in the case they are still even developed).

I would be tempted to write a proof-of-concept myself (it would be easy as you say), but I literally have no time at the moment, and in the forseable future I will be spending what little time I have on finishing PortablE r6. Plus such a program really needs to come with the OS anyway, for it to be easily used by users.
chris
Posts: 562
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: UrlOpen needs Arexx Support

Post by chris »

ChrisH wrote:That might be true in principle, but in practice we are still here 1-2 years later (or possibly longer) with both Timberwolf & MUI-OWB not working correctly with URLOpen. Not to mention RA-OWB, probably IBrowse, and possibly even NetSurf (I can't check at the moment).
NetSurf works, but it re-launches the entire program before it sends the command to the existing session and exits, so it's less than ideal.

I don't intend to split it into two just for the sake of launch-handler, although I might write an ARexx script to do the job. But that kind of defeats the object of avoiding ARexx support in launch-handler, doesn't it?

I don't really see the problem with adding ARexx support - it's just a matter of sending commands to ARexx ports, and that's exactly the same as how Python communicates with ARexx-capable programs. The 68k parts of ARexx are AFAIK to do with the interpreter - sending ARexx commands between programs doesn't need to touch that.

Also note it's not only web browsers - launch-handler supports mailto: and can be extended to add ftp: and all sorts of other links. OpenURL also supports mailto and ftp links so it's likely software already has the necessary ARexx commands.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: UrlOpen needs Arexx Support

Post by colinw »

chris wrote: NetSurf works, but it re-launches the entire program before it sends the command to the existing session and exits, so it's less than ideal.
I don't intend to split it into two just for the sake of launch-handler, although I might write an ARexx script to do the job. But that kind of defeats the object of avoiding ARexx support in launch-handler, doesn't it?
...
I'm sure I don't have to give you detailed instructions, you are perfectly capable of working it out yourself, nevertheless,
here's a simple senario that would work....

1: Rename the main executable to say, "NetSurf.bin" and write a small loader called "NetSurf" to handle both WB and CLI startup.
2: In this loader exe, check for your public port, if it's NOT there, start "PROGDIR:NetSurf.bin" with IDOS->SystemTags(ASYNC).
3: Wait for the port to appear and send a message to it, (of whatever type you choose), to perform the required action.
4: "Netsurf" loader executable now exits.

The users will never know the difference and it will still work transparently on any platform you wish to support.

Also, for larger executables like Timberwolf, you won't have that "dead" time waiting for something to happen,
the loader can post a splash window / snooze pointer before it tries to load it, so the user gets immediate feedback.

Larger programs like this are likely to be even more common in the future, as the number of ports and the sheer
complexity of programs increase, this is also another important reason to do it this way, because it simply can't be
done with just one huge executable.
Post Reply