The idea that there exists in the system a central database documenting ARexx commands as used by various applications, and a tool for browsing this database, is nice but a few questions spring to mind:
1. Do I understand it correctly that the project actually aims at moving ARexx command documentation from one place (the app's manual) to another (the central database)?
2. Apart from having ARexx docs under one roof and accessible from one place, what other benefits are there? For example, will there be a public API for applications to query the database about another application's command set, to be able to send a respective command?
3. From the project description it looks like programmers will have to provide the command set in a standardized (XML) file distributed as part of the app's installation. They'll also have to update it whenever something changes in the command set. The database browser tool will then scan installed applications for the presence of these XML files, and display their contents. I guess there will be a notification mechanism to watch for new XML files being added or updated?
5. Do you think the project is useful enough to be worth all the trouble? Is it apt to become a future AmigaOS component, especially that ARexx is officially a dead end because of licensing?
It seems this project is about applications and their public arexx ports and not arexx itself.
Does the arexx license include the arexx language alone or the arexx port technology as well? I'd guess the former so then it would not really be important which language that is calling the ports since that can be done from whichever scripting language that is used in the future provided that it is extended to handle it.
It seems this project is about applications and their public arexx ports and not arexx itself.
I understand that. But due to ARexx being an end-of-life product, ARexx-based communication between Amiga applications can be (and I'm sure will be) ditched as soon as there is a suitable alternative. My question is whether time and effort should be spent on developing an AmigaOS component relating to something that is doomed to be on its way out. As a third-part tool to aggregate ARexx documentation, perhaps. As an OS component, I don't think so.
My initial plan is to create a light database server which has a public API (ARexx port and a small command set) for storing, updating, deleting, and querying programs' ARexx command descriptions.
The server can export ARexx command descriptions of a desired program as text, AmigaGuide, or HTML. The application which requested the command descriptions can then display the file.
It is also possible to search and fetch information from the database through the API. Then the caller application will get the requested information as a message.
Like trixie said, I expect the application programmer to make an XML file containing his application's ARexx commands data. When the XML file is handed over to the database server, the server stores the information in the database.
I haven't thought much about the database browser tool. I'll concentrate on the server first and try to make it as light and simple as possible.
So it's more than just an I'm-too-lazy-to-read-docs browser tool to sit in your SYS:Utilities drawer; good
Quote:
I expect the application programmer to make an XML file containing his application's ARexx commands data. When the XML file is handed over to the database server, the server stores the information in the database.
If this XML file contains the program's complete command set, including a description of what each particular command does, have you thought of how you will handle localization here? As the thing will feature a public API through which data can be obtained and displayed, it must absolutely-doodly be localizable if it is ever to become an OS component.
My other problem is the very use of an external file. As a programmer, I'll have to implement the command set in the code and write an XML descriptor for it. This essentially means doing the same work twice.
This is what I'd suggest doing:
I'm currently developing a BOOPSI Application Class through which you can, among other things, define an ARexx command set for your program. What if I extend the definition to also include a command description (localizable from your program's catalog), and the class sends the data to your server automatically when the program starts up? Unlike with using external files (which doesn't guarantee synchronization between the program and the XML file), the command set would always be up-to-date because what is defined in the program will appear in your database.
For older programs unable to use the Application Class you can resort to your XML solution.
I'm currently developing a BOOPSI Application Class through which you can, among other things, define an ARexx command set for your program. What if I extend the definition to also include a command description (localizable from your program's catalog), and the class sends the data to your server automatically when the program starts up? Unlike with using external files (which doesn't guarantee synchronization between the program and the XML file), the command set would always be up-to-date because what is defined in the program will appear in your database.
Or maybe implement a standardised HELP command which gives this information in a standard format. Programs not using application.class can implement it themselves. It could be added to arexx.class too.
@jap
You only need plain text: COMMAND TEMPLATE (ReadArgs format) <blank line> DESCRIPTION
Do it AutoDoc format if you want something standard. The standard ARexx command to dump it could then be AUTODOC, which probably isn't used anywhere currently.
Scan ARexx ports, send that command, capture the output to the database. When new stuff starts up send the command, capture and update the database. Readily-available AutoDoc viewers can be used or tweaked to view the output from the database.
Don't rely on people creating extra XML files, they won't. Programmers are lazy and XML is horrid.
Personally I'm not entirely sure how useful this project is, as the information is in the application's standard documentation anyway.
Personally I'm not entirely sure how useful this project is, as the information is in the application's standard documentation anyway.
I'm not convinced either, hence all the questions
What is important is that we discuss OpenAmiga projects here in this forum - I'd like to encourage all participating programmers to do that. Feedback can eliminate potentially useless or ill-conceived projects before people start wasting their time on them. And, other people can give you all sorts of ideas for a better implementation, which is good.
Quote:
It could be added to arexx.class too.
ARexx Class was the first to come to my mind but as Jap wants to display ARexx-related data per application, and ARexx Class knows nothing about which application the command set belongs to, I moved over to the Application Class level. (But Application Class internally uses ARexx Class, of course.)
I think a reasonable first little step would be to modify the ARexxCmd structure in <classes/arexx.h>. There is an unused uint32 field which could be turned into a STRPTR to point to the command description, without sacrificing backwards compatibility (older apps will have this field set to NULL, as per the current specification). Then we can start thinking about how to retrieve this information from the class, if there is a need to use it. There are many possible ways.
Quote:
Don't rely on people creating extra XML files, they won't. Programmers are lazy
My opinion, too. Looks like too much work for too little benefit.
Maybe the project was suggested just because people find the available documentation poor - it's too difficult to find information on supported ARexx commands for each application.
If that is the case, is this just a matter of improving the documentation then? We have a Help tool already: SYS:System/Help. Why create another application? If the developer creates a separate autodoc on ARexx commands supported by his application, that autodoc could be read with the Help tool when saved to "HELP:<language>" directory. (In order to work, Help tool would need a small update, of course.)
Maybe the project was suggested just because people find the available documentation poor - it's too difficult to find information on supported ARexx commands for each application.
It would appear to be the case. I can understand why someone might want to concentrate all ARexx-related information under one roof (I remember in the past there was a guy who compiled information about all BOOPSI classes available across the various toolkits and distributions; his motivation was probably similar). But how often do applications' ARexx command sets change, and why do we need a central server to keep track of this? What shall we use the information for other than simply read it? Sounds like an overkill to me. Too much work for too little luxury.
But how often do applications' ARexx command sets change, and why do we need a central server to keep track of this? What shall we use the information for other than simply read it? Sounds like an overkill to me.
I can see a small benefit in being able to query whether a command is supported by an application, or to find out which version it was added in, but as you say how often do these change? If you're running the wrong version the script will exit with an error anyway. If the script is written properly (and the application it is using supplies version info via ARexx), this shouldn't even be an issue.
Quote:
ARexx Class was the first to come to my mind but as Jap wants to display ARexx-related data per application, and ARexx Class knows nothing about which application the command set belongs to, I moved over to the Application Class level. (But Application Class internally uses ARexx Class, of course.)
True. But it knows the port name, which is usually the same as the application name.
Quote:
I think a reasonable first little step would be to modify the ARexxCmd structure in <classes/arexx.h>. There is an unused uint32 field which could be turned into a STRPTR to point to the command description, without sacrificing backwards compatibility (older apps will have this field set to NULL, as per the current specification). Then we can start thinking about how to retrieve this information from the class, if there is a need to use it. There are many possible ways.
Sounds good to me. There is definitely a benefit in having a system-wide Arexx HELP command, to get the command name, template and a short description of what it does. MUI has something similar already, although a quick test reveals it just dumps this info to the program's stdout, which is a bit rubbish. It would be better being copied into RESULT if it can't be printed to the calling process' stdout or a proper window designed for this purpose.
If this is implemented at the arexx.class level then even old applications would support it, sans command description of course.
Quote:
Too much work for too little luxury.
Agreed. There are more important things to work on.
ARexx-based communication between Amiga applications can be (and I'm sure will be) ditched as soon as there is a suitable alternative.
There is : Gui4Cli has its own "port system" that can be added to any application, just as arexx. Of course Gui4Cli written programs can also acces arexx ports.
IMHO a better solution (than the assigned project) would be if each application just supported a HELP command on it's ARexx interface: On it's own it would list all commands, and when used like "HELP command" it would describe that command in more detail.
Looks like most agree the problem is on the application side rather than a shortage in the operating system. I'd therefore suggest closing this project, as it isn't really in line with OpenAmiga's mission. The project submitter can get it developed elsewhere, of course.
There's no such thing as an "Arexx port". They're public Exec ports. For example Python supports them. "Arexx port" is street language.
+1
Exactly, The demise of AREXX does not necessarily mean the demise of the "arexx" ports.
@All
I propose that this project is redefined to involve creating a proposal for a standard way of querying applications for the calls and their parameters that are available on their "arexx" port.
The project should deliver the following artifacts:
Part 1: - A document describing the standard method with examples. - A small test application + source with the new method - An executable intended for the C folder that will output all available calls and parameters of a running application/port to the console.
Part 2: - A graphical application for the tools or utility folder that lists all public "arexx" ports that are currently available and with a click on a port lists all available commands and their parameters.
The idea to have a better help system is not bad. What could be done is:
update the current Help AmigaOS command to add an item "Application ports" in the cycle gadget. When it is selected, display all applications registered in application.library and declared as "having a message port". When the user clicks on an application, the Help command will run the tool with the "HELP" command to retrieve the internal documentation and display the result in the Help window.
Note: maybe application.library needs an update to handle the "application has a port" information.
a proposal for a standard way of querying applications for the calls and their parameters that are available on their "arexx" port.
As Elwood suggests, I'd go with Application Library - it operates system wide, and after all, an ARexx interface is an application-level feature. If there's a way for the programmer to pass a documented ARexx command set as part of app registration, you could then use IApplication->GetApplicationAttrs() to query about it. You don't need to invent any other "standard ways" - the OS already has everything in place to support querying about application parameters. The Application Library just needs to be extended to cover this particular bit.
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
