Welmat Programming Language - WPL --------------------------------- WPL is the new interpreted language for writing network mailers and other telecommunications utilities. The language is designed to be very extendable by third party developers, and makes use of a grouping of shared libraries with a standardized interface. The application previously called 'Welmat' and this language have a few things in common. Firstly, the original Welmat source code was used as a shell during the development of this language so that things could be upgraded in stages. At this point the majority of the code has been re-written, and most of what used to be called 'WELMAT' is now housed in an XPR library called 'xprfts.library' that is an optional external transfer protocol. Secondly, the development philosophy and distribution license for the program called 'WELMAT' is being used. This new language is licensed under the GNU public license and is aimed at providing very powerful and configurable tools to allow the users to determine their own personal networking environments. Thirdly, the name 'WELMAT' is being kept as the name of the support conference, it is the 'W' in 'WPL', and there is a hope that a 'WCompile' program to make use of the old V0 Welmat config files will be written. At last, many of the origional Welmat enthusiests are getting involved with the development, beta testing and support of this new language and related tools. The similarities between WPL and the application called WELMAT pretty much end there. This new language is just that : A LANGUAGE. With this language comes many different 'levels' of users ranging from people who would need to be 'C' and Assembly programmers, to people who might not even know how to run a CLI command: a) WPI (Welmat Programmers Interface) developers - People who would make use of 'wpl.library' and other tools common to the WPL environment in language extension libraries, etc [Note: Any of the old WELMAT programs that talked to the 'WelmatMAST' message port (wctl, WNotify, wabort, etc), as well as any flow.library supporting utilities do not work in conjunction with WPL.] b) WPL developers - People who write mailers, BBS's, terminal packages or other applications in the new WPL language. These people could also be the authors of programs such as WCompile, WelmatPrefs, etc which would in one way or another generate a 'WPL script' that would contain the functionality of the 'application'. These developers might also include the various REXX and FPL developers who would be making use of the various language gateways to these telecommunications tools. c) While not really 'WPL specific', any author working on an XPR supporting file transfer protocol, especially those that are working on libraries that might conform to the future 'XPR 3.0' proposals would be able to make use of WPL as their host, and any WPL developers would be able to make use of these file transport protocols in their applications. Anyone interested in this level of development are strongly encouraged to get connected to the XPR mailing list for future XPR development discussion (More information provided in the 'XPR' section of this readme). d) While again not 'WPL specific', any author working on xferq.library supporting file request handlers, tosser/scanners, outbound list managers, etc would also be able to make use of WPL as their host. Regardless of whether an author wishes to use WPL itself, adding support for XferQ is extremely highly recommended as it will likely become the future standard in outbound queue management for the Amiga. [information available from David Jones (dej@qpoint.ocunix.on.ca)] e) User level - This would constitute the majority of people using WPL based systems. These people would need no knowledge of any tools other than the programs that will be generating the 'WPL scripts' that will be their mailer. People in this group could be using mailers that are configured much like the old Welmat V0 config files, or with newer systems such as the proposed WelmatPrefs program (A program that will make setting up a network mailer as simple as setting up ones screen preferences). *NOTE*: WPL is an internal language that will likely be used by less than 10% of the users that will be making use of the new environment. Unless you are an extreme power user, it is recommended that you wait to do any mailer beta testing until some of the configuration editors are being written. Learning WPL,WPI,etc is not required, nor even recommended for the majority of users!!! It is my hope that in the future the various 'user levels' will be able to have their own support people. I myself would love to be able to write networking tools that I would then support to people at the first and second level. These people in turn would write 'user applications' that they would support to the actual users as they would be more familiar with configuration issues with their tools than anyone else. This would allow for much more people to be involved, and for much better user support for all the various types of users that exist. One of the problems, for instance, with the current 'WELMAT' support conference is that people at the 'User Level' are almost shut out by the people at the 'WPL developer' level. For this reason I am in the process of setting up an alternate WPL-PROGRAMMER support conference so that another conference WPL-_APPLICATION will be left for 'User Level' support of the various applications that will emerge. -------------------------------------------------------------------------------- WPL Support ----------- Before moving into discussing how WPL itself works, I thought I should mention methods of asking questions. I find that with a new language that there is a fairly high initial learning curve, but that things get easier once the initial problems are worked out. Since WPL is a mailer language that can be used by people in many different types of networks, support exists in many forms: Fidonet Email Support: Russell McOrmond@fidonet#1:1/139 Internet Email Support: aa302@freenet.carleton.ca Old Fido support Echo : WELMAT Note: The support conference for the old program 'WELMAT' is only temporarily being used until the new support conferences can be added to the backbone. I wish to eventually vacate this conference, and leave it available for people to actually discuss the old 'Welmat' program. Programmer support echo: WPL_PROG [yet to be added to backbone] Programmer support list: wpl-programmer@alfred.ccs.carleton.ca Requests to join the list: wpl-programmer-request@alfred.ccs.carleton.ca This conference is aimed at the more technical aspects of the use of WPL as a language, and as an expandable library system. It is requested that support questions of users not developing in WPL, C, assembly, ETC to put their questions into WPL-APPLICATION. User support echo: WPL_APP [yet to be added to backbone] User support list: wpl-application@alfred.ccs.carleton.ca Requests to join the list: wpl-application-request@alfred.ccs.carleton.ca This conference is aimed at the 'Users' of WPL based application scripts, GUI configuration editors, and other such things. This is an open forum between the WPL developers and the users of their applications. It is requested that this conference remain as non-technical as possible. Various WPL representatives also frequent the Fidonet echomail conferences AMIGA_NET_DEV and AMY_POINT, as well as the usenet conferences comp.sys.amiga.datacomm and alt.sys.amiga.uucp -------------------------------------------------------------------------------- What is required to run WPL? ---------------------------- Required: Before attempting to set up WPL, the following should be located. - WPL requires AmigaDOS 2.04 (Kickstart V37) or higher. - The main binary for wpl (wpl.library along with LOADSCRIPT and LAUNCH). (Magic name only available in support conference currently) - xferq.library (Now in public testing) - xprzedzap, xprfts and any other XPR's you require for the protocols you wish to run. - A configuration program generator such as JamMail, or knowledge of WPL in order to write your own configuration script. Optional: (Notes about PackMGR, FlowMGR , RFS and TLlookup sent by Robert Williamson.) - If you are using a Tosser/Scanner that uses 4-D .OUT files, JBundle or PackMGR is recommended for compression. - If you are using a Tosser/Scanner that uses .FLO files, some sort of 'conversion' utility such as ScanWork or the arexx function host FlowMGR is needed. - If you wish to support file requests, XFreqSH may be used with virtually any freq handler, or some XferQ supporting file request handler such as RFS is needed. - If you wish to support UUCP, Login is currently recommended. - A nodelist 'lookup' program is required for nodelist support. Support programs for both traplist.library (Jamtool, TLlookup) and IGEN's 'nodelist.library' (JamTool, Lookup) exists. - to write XferQ supporting scripts or programs, the full XferQ documentation is a must. - To edit your outbound queue, XTool is currently recommended.