So then define the project to cover that and wrap it up in a document with suggested autodoc entries and descriptions on a way for the end user (not just a C developer) to access the information. With a skeleton shell program and a graphical program that Hyperion can easily add the necessary calls to application library to.
1. Design a datastructure to hold information about an ARexx command (name, template, description).
2. Add two new tags, REGAPP_ARexxCommands (OM_NEW only) and APPATTR_ARexxCommands (OM_GET only) to Application Library.
3. Pass a NULL-terminated field of command datastructures via REGAPP_ARexxCommands at registration time.
4. If an app needs to query about another app's command table, it can GetApplicationAttrs() the structure field from APPATTR_ARexxCommands and process the field as required.
Document done No need to introduce new function calls in the library - just the two tags and the datastructure. Estimated implementation time: 15 minutes.
A random forum post is not a proper way to finish a project. Before this can be transferred to Hyperion it needs to sit in a document that gives proper background information (why and how) and a description of the general solution as well as a detailed description. Information that Hyperion can easily incorporate into the SDK documentation.
Also this needs the two applications to be developed.
Nothing will happen on the Hyperion side unless this is presented to them in a proper way. Well unless there's someone in the team that just happens to have some time to do it after reading this thread (terribly unlikely) or just being very energetic about the whole thing (also terribly unlikely).
The less Hyperion has to do the more likely it is that it will happen.
I know, of course. But why don't we discuss and design the datastructure here (or the actual implementation - my suggestion was just an idea), with developer feedback, and then copy it all over to the proposal document for Hyperion?
So what do you think about the solution I've proposed in this post above?
Advantages:
- No need to design another component. - System-wide use. - Uses Application Library's API. - The ARexx command table description is treated as any other application parameter. As such, any registered app can access this information using the existing library functions FindApplication() and GetApplicationAttrs(). - Easy implementation: requires adding two attribute tags and one datastructure in <libraries/application.h>
Of course, there will be a BOOPSI frontend to this, so apps defining their ARexx commands through my Application Class will not need to do anything else - the class will use the command table definition to construct the ARexxCmdDescription field, and will pass it to Application Library automatically as part of app registration. (The general aim of Application Class is to hide the library from you, among other things.)
I think if an ARexx command structure is being added to application.library, then that should handle the arexx.class interface. Otherwise I'd ignore application.library and just do it through your application.class.
Alternatively, arexx.class needs to have a way of presenting this information (eg. through a standard HELP command). It's duplicate work for the developer otherwise.
My preferred approach would be to add it to arexx.class, extend the structure as you suggested before with a description (or a Help structure of some sort, with a short and extended description), and make arexx.class handle any HELP command internally.
If it chucks the relevant data into RESULT, then it's a cinch to capture that with another application (or the existing Help program, as suggested earlier).
So you get: SYS:System/Help - extended with "ARexx capable apps" or "scriptable applications" or somesuch in the cycle gadget. When selected, this gives a list of running applications with an ARexx - or scripting if we're trying to make it more generic - port in the left-hand list. Clicking an item on the left sends a HELP command to that application. If it supports this - ie. if arexx.class is being used, or the program has been written to comply with the same spec - it returns a list of supported commands in RESULT, one on each line, (and optionally) a tab character, the template, another tab, and a short description. The Help application can then allow the user to click on one of these lines. When the user does that, it sends a HELP COMMAND command to the application's ARexx port. If handled by arexx.class or a compliant application, this then returns a full description (which could conform to the same formatting rules as the CLI commands help files) for COMMAND in RESULT. The Help application then displays this.
That's how I'd do it anyway. The advantage is all existing arexx.class-using apps get some sort of support automatically, and it's minimal effort for the programmer to add some extra documentation. Even the lazy programmer who sets descriptions to NULL will still get their command set and templates listed in Help. As a bonus, it can be queried from the command line with rx "options results; address MyGreatApp 'HELP'; say result".
This should be doable as a proof-of-concept by subclassing arexx.class and making that handle the HELP command and descriptions.
This thread has got quite long before I even started reading it so quoting is awkward.
But for some time we've had a "weak standard" wrt to the HELP command which I follow with my more recent applications
ie
HELP COMMAND/K
HELP returns a lists of commands HELP COMMAND return the command with command template.
IMHO actually documentation should be provided in the application authors preferred format. Embedding this in the app adds bloat, ideally it should be distributed with the app documentation and also on the application website. More just make more work for overstretch developers.
ARexx as an interface concept isn't going anywhere, I add support for it any scripting language I port (where useful) I added it to perl and javascript recently, not sure if it will get added to guile or not.
I don't understand why you want to add Arexx support to application library, we have arexx.class allready, your various comments and suggestions seem to be adding redundancy and duplicate effort for the developer.
The one problem with automating the HELP command in arexx.class is it might mess up the apps that provide there own. That and not everybody uses arexx.class. It's easy to use and I do for most of my apps, but in other contexts using simple rexx is better.
Also ARexx / Python / Perl scripts can be host them selves.
I don't understand why you want to add Arexx support to application library, we have arexx.class allready
It's because whenever I suggest something based on BOOPSI, there always comes someone crying "Ooooh, this feature should be available to all programs, not only those that use BOOPSI!" I suggested Application Library because it provides system-wide information about applications and their features. With the solution I outlined, an application could: - find out which running apps actually have an ARexx port; - obtain a documented list of its ARexx commands.
If such a feature is useful, that is.
Quote:
Embedding this in the app adds bloat, ideally it should be distributed with the app documentation and also on the application website.
I absolutely agree with you on this, and that's why I first suggested closing the project because it tries to address a documentation problem and not a shortage in the OS. Orgin nevertheless insisted on redefining the project to a new specification, and being the good guy I am I presented a possible solution. Not that I'm particularly interested in what the project is trying to achieve
The one problem with automating the HELP command in arexx.class is it might mess up the apps that provide there own.
Well, arexx.class will know that, as it has the complete command list for the application. So in those cases it an opt not to provide the in-built HELP command.
Quote:
That and not everybody uses arexx.class. It's easy to use and I do for most of my apps, but in other contexts using simple rexx is better.
Hence the "or other application conforming to the spec".
I don't think it's infallible, but if arexx.class provides some sort of command list by default then that could be helpful, even if that's as far as this goes. (like trixie, I'm uncertain as to how beneficial this project is)
1) Research. Find out what worthwhile applications have an arexx port. Trawl through webpages, program guides and pdfs to find out to what extent functionality of arexx they in fact cover; making notes of urls and reference points.
Reading this, to me it seems this project would be better off with some sort of wiki-approach. The objective seem to be primarily documenting which legacy applications have ARexx ports. And for that I think a community-based, non-OS4-specific wiki would be ideal.
A feature that I do miss, is the ability to query any generic application of its ARexx commands. Much like you can do with all Amiga DOS command, with the question mark argument. I'm thinking this must be possible for an external program to see, for any running application, since the arguments and command name are registered at some point.
Quote:
There's no such thing as an "Arexx port". They're public Exec ports. For example Python supports them. "Arexx port" is street language.
This is a fact not terribly widely known, and it seems that also official streets call them "ARexx ports". The offical autodocs (arexx.class) for instance says: Quote:
It will setup a unique ARexx port, start ARexx macros, parse commands and dispatch command handler functions.
I personally think "ARexx ports" is the best AmigaOS features of all, and I'm happy to hear they're not deprecated. As for the ARexx language -- I've grown accustomed to it, but it's not really that great.
There's no such thing as an "Arexx port". They're public Exec ports. For example Python supports them. "Arexx port" is street language.
This is a fact not terribly widely known, and it seems that also official streets call them "ARexx ports".
If we're not calling them ARexx ports, then something like "scripting port" is a better name. Message port is far too generic, AmigaOS uses message ports for everything and you can't send commands from ARexx to most of them.
Quote:
I personally think "ARexx ports" is the best AmigaOS features of all, and I'm happy to hear they're not deprecated. As for the ARexx language -- I've grown accustomed to it, but it's not really that great.
Could we see the ability to send commands to ARexx ports in JAmiga?
There's no difference between a general message port and an ARexx port. This makes systems that want to auto query ARexx commands sets tricky as you can only see a list of public portnames some of which may be for totally different purposes, sending the wrong kind of message to a port can sometimes be fatal.
As to the name, an ARexx port might be considered an ARexx port even if the scripting laguagesending mesages is not ARexx for two reasons,
1. Tradition / habbit
2. The appliaction expects to recieve a message of type RexxMsg at that port, thus what ever the source of the message it's still sent to a Arexx port.
There's no difference between a general message port and an ARexx port. This makes systems that want to auto query ARexx commands sets tricky as you can only see a list of public portnames some of which may be for totally different purposes, sending the wrong kind of message to a port can sometimes be fatal.
True - currently there is no way of asking an application about its ARexx port name. Relying on the unwritten convention that the port name is an uppercase version of the application name is absolutely unsafe - the name can include an instance counter, for example.
This is another opportunity for the Application Library to come and be useful. If applications could register their ARexx port name (just like they register other properties), other apps could GetApplicationAttrs() the port name and only then send a message to it. (A similar ask-me-and-send mechanism is already in place for the library's own messages.) Again, would be dead easy to implement.
I don't understand why you want to add Arexx support to application library, we have arexx.class allready, your various comments and suggestions seem to be adding redundancy and duplicate effort for the developer.
I think I agree with you. I read the description of the project and it sounds like it should be a simple compilation of text files and a program like "SYS:System/Help" to access the files. Why complicate it with some special format like XML and add functions to application.library or arexx.class??
Why not an improved version of SYS:System/Help that reads simple text files? It would be simple for an application author to create files for ARexx commands with a format similar to the DOS help files ( SYS:Locale/Help/english/Shell/ ). The user would just need to drag a directory to a predetermined location on his system partition. The application could also look in the program directory for the ARexx documentation directory if the user prefers not to have consolidated ARexx documentation.
If the ARexx docs are simple text files then users could create ARexx docs for older applications and contribute them to the ARexx Dictionary project. The more people we can get involved, the more likely it is that a comprehensive database of ARexx commands can be created.
Lets stick to the KISS principal with this.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Relying on the unwritten convention that the port name is an uppercase version of the application name is absolutely unsafe
It's not unwritten, it's in one of the style guides, but not rigidly adhered to and and of cousre not enforcable in any way.
Quote:
This is another opportunity for the Application Library to come and be useful. If applications could register their ARexx port name (just like they register other properties), other apps could GetApplicationAttrs() the port name and only then send a message to it. (A similar ask-me-and-send mechanism is already in place for the library's own messages.) Again, would be dead easy to implement.
But utterly pointless. No disrespect intended.
If you are writing a script for an application, you allready *know* what it portname is, the only subtley might be determining the counter in multiple instance situations. In aps using the AWeb style, seperate port for each window, you can query the active window from the appliactions ARexxAPI (if you can't the API is broken), in the opposite case of separate instances, you'd have separate appliaction library instances too, so would need to know which instance to query, so you are still no better of.
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
No need to introduce new function calls in the library - just the two tags and the datastructure. Estimated implementation time: 15 minutes.
