So, situation is that we have on os4 2 implementations of the handling of usuall protocols between apps: http, https, mailto and file.
One come by default with os4, called urlopen , prefs are prefs:url, and when you use it, you always have some nice looking window where you can choice by what app you can handle your link. Sadly it didn't have support of Arexx, but that can be easy workorounded by creating arexx scripts which deal with (i.e. you will be able to use the same arexx commands via that stub rexx scripts and via urlopen). So only limitation is that you need write those scripts (or use already done ones, by someone else as in end it will be probably).
Second one, is 3d party and opensources "openurl". With mui based prefs (prefs:openurl), different way of handling links (no fancy-shamncy window where you can choice, but all just controlled via prefs), and with rexx support (so you just use rexx commands inside of prefs, without needs to create/use rexx stubs).
Now, question is: should we have in os4 port of odyssey or openurl (3d party) support, or, instead support of urlopen (default in os4). Its of course possible to have support of both (like check if openurl installed, then use it, if no ,then urlopen). But imho that a bit of mess.
My idea is just complitely use urlopen , and supply helpfull arexx scripts which will deal with everything (and for http, and for mailtos, etc). If not with odyssey itself, then somewhere on the web. Probably even those scripts will be not need it, as they only to help to use arexx commands, and if one want it, he always can create any script yourself as he already works with arexx.
But intersting to know what other think about.
But be noted if making 2 at same time, then it will be like this: if openurl is installed, that mean it will be handled first, so no urlopen (ever). Default urlopen will works only when there is no openurl will be installed => mess.
Edited by kas1e on 2014/4/17 14:46:45 Edited by kas1e on 2014/4/17 14:58:15
@Chris Just for making arexx works on top of it ? But then one more openurl.library will make more mess (imho). As let's say developer will open openurl.library, but it can or can not works as he want, because there may, or may not be stub.
I think the stub library is the way to go but as part of the OS.
In the past I've requested that developers of programs add support for urlopen and have openurl as a fallback and been told to go and do something physically impossible and install openurl as they refuse to change their code.
The stub brings compatability and consistancy without having to install 3rd party apps.
Amiga user since 1985 AOS4, A-EON, IBrowse & Alinea Betatester
add support for urlopen and have openurl as a fallback
But imho, as urlopen are default and inbuild with os, there is no needs to have fallback. Because urlopen can't file, if not only user borks system (but that his fault).
I mean, having support of urlopen will be already enough, as it will works out of box in all cases. + we will have no needs to install anything and have no mess.
Quote:
The stub brings compatability and consistancy without having to install 3rd party apps.
mm.. but if developer firstly use urlopen (what mean there never will be any fallback to openurl, as urlopen default and always here), then there is no reasons to have any stub for openurl.library too (well, maybe for some old apps or something).
The way I did it in Digital Universe was to use both. If OpenURL is available that is used (as at the time URLTesxt.mcc only worked with OpenURL), but if OpenURL is not available I used URLOpen. A final fallback for anyone daft enough to be still using OS4.0 was to just print the addresses.
I think URLText.mcc, native version, can now use both OpenURL and URLOpen, so having OpenURL is not as advantageous as it used to be.
The problem is URLOpen is really badly designed, and not having REXX support is just unacceptable. If URLOpen wasn't so limited, the choice would be easy.
There is absolutely no need for a stub library or any other workaround. For AmigaOS4 you can just try the URL: device first. If opening the URL that way fails (i.e. because URL: is not mounted) then fall back to openurl.library. If people don't like URLOpen then all they need to do is to move URL out of DEVS:DOSDrivers. Those who like it just leave it there. YAM does it exactly this way.
That doesn't help with the situation that we currently need to configure everything twice.
There should be one point of configuration no matter whether OpenURL or launch-handler is used.
I also agree with Fab, that the lack of any fine control in launch-handler sucks. I sort of understand the reasons for it, but it does limit the usefulness, especially when running things that haven't been created with launch-handler in mind.
I actually think adopting openurl.library for OS4, and writing a ReAction version of the Prefs GUI, would have been a better approach, but it's too late for that now.
What else wrong in urlopen except not having arexx support ?
@All
While Thores suggestion are good for having both, i still do not know if there needs to have both at all. I mean ok, urlopen miss arexx support, but who care if it can parse what it should parse and in weird cases additional scripts can be done which can handle everything.
Someone may say "but additional scripts needs knowledge", but imho setuping openurl/urloen with all that mambo-jambo already mean to have some knowledge. One script more, one less, no big differences.
I don't see why an Arexx script is needed in such tool as both program are called in the command line with "program url" (like: urlopen http...).
For examlpe when you want to use arexx functionality like "open in new tab". I do not know if any of our browser have in command line arugments for opening in new tabs instead of new instances (probably none, because its clumsy and sucky to run binary all the time for just control already running app). For netsurf Chris make a rexx script for , as well as for odyssey i make one too:
options results
parse arg url
if lastpos("ODYSSEY", SHOW(PORTS)) > 0 then do
address ODYSSEY.1
OPEN NAME url NEWPAGE
end
else do
address command 'APPDIR:Odyssey' url
end
Placed that to rexx:odyssey, and instead of appdir:odyssey , call rexx:odyssey (that script) from the prefs:url, for all tabs except mailto. But probably for mailto also need script, which also will check if mail client already running, so or open new instance, or instead just call to "new mail" in already opened client. Without arexx i do not know how it all will be and can be. Probably some other ugly scripts can be done, but there is arexx already.
So, if there is no running odyssey when we click on http link, then new instance will spawns. But if there is already new instance, then open in new tab.
I do not know how without arexx and by simple command line do that. If it possible to do in owb/odyssey/netsurf/everything, then it can be good. But as Chris do it like this as well for netsurf, that mean that command line != arexx support, and arexx support mean more options to choice and more control.
That "open in new tab instead of new instance" only as example (just one of necessary features). + you can't have from command line all necessary control. And its suck for every "feature" run new binary again, instead of just sending something to arexx port (which is much faster of course).
Quote:
In a program I would write some code "if in OS4 use URLopen, else use OpenURL". Thore suggestion works too.
I am about pure os4 version of odyssey, those ifdefs will have no place in fab's code, so there is no reasons to worry about other oses, just about os4 (for mos by default openurl already in use by fab).
Edited by kas1e on 2014/4/18 11:32:44 Edited by kas1e on 2014/4/18 11:34:20
I actually think adopting openurl.library for OS4, and writing a ReAction version of the Prefs GUI, would have been a better approach, but it's too late for that now.
Perhaps there was a legal issue with using openurl.library as an OS component?
I do not know how without arexx and by simple command line do that.
It's possible, but you'd need to add the commands to Odyssey's arguments. It then needs to detect if it is already running and send the commands across. This is how NetSurf does it, but because of the long-ish startup time, the ARexx script is better (it also has the side-effect of being able to open the page in a new tab, but that's nothing that couldn't be added to the command line args)
TuneNet has a set of command-line arguments that control the running instance, if you want a more extreme example.
Quote:
If it possible to do in owb/odyssey/netsurf/everything, then it can be good. But as Chris do it like this as well for netsurf, that mean that command line != arexx support, and arexx support mean more options to choice and more control.
It's definitely easier/quicker to do this with ARexx.
The official way is to have a launcher program which does it all, but that seems like a lot of effort for little extra benefit.
Actually it seems to be the sort of thing we should be doing if we didn't have ARexx.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
