home *** CD-ROM | disk | FTP | other *** search
- FDRPR - FrontDoor Request Processor for RA // Absolute Solutions
- ----------------------------------------------------------------
-
- Copyright 1993, 1994 Mats Wallin; All rights reserved.
-
-
- Introduction
- ------------
-
- FDRPR is a Request Processor for RemoteAccess. A Request
- Processor is a program that FrontDoor executes whenever it
- receives a file request. It is then the Request Processor
- that processes the list of requested files, and returns
- a list of files to FrontDoor, that FrontDoor then will
- send.
-
- The advantage with a Request Processor, is that it can
- be adapted for a special BBS program, or any other
- program on the system that uses the Request Processor.
-
- This Request Processor uses the advantages of the file
- system that RemoteAccess 2.00 and later versions uses.
- This will speed up most file requests, especially for
- systems using CD-ROMs, or accesses the file area over
- a network. It will also, optionally, update the download
- counters for requested files.
-
- Another advantage of this Request Processor, is the possibility
- to "check" a file request locally. E.g. you can run it
- manually, and see what the result of a file request would
- be for the system requesting files.
-
- One more advantage with this request processor, and that is
- the possibility for it to return a message to the requesting
- system, containing the descriptions of the requested files.
-
-
-
- Requirements
- ------------
-
- FDRPR requires the following thing to run:
-
- * A 80286 processor or higher
-
- * FrontDoor 2.11 or later
-
- * RemoteAccess 2.00 or later
-
- * The environment variable FD pointing to the directory
- where SETUP.FD is located, or SETUP.FD in the current
- directory
-
- * A list of requestable directories in the file specified
- in FDSETUP.
-
- * The environment variable RA pointing to the directory
- where CONFIG.RA is located, or CONFIG.RA in the current
- directory
-
-
- Installation
- ------------
-
- It's very easy to install FDRPR. All that is needed, is to
- copy the files in the distribution archive to the directory
- you would like it be in, and then type:
-
- FDRPR INSTALL
-
- The program will then make the necessary changes to your
- SETUP.FD file, and FD will in the future use FDRPR when
- a file request is received.
-
- You should probably also study, and modify, the included
- FDRPR.CFG file, to make sure FDRPR behaves the way you
- would prefer.
-
- FDRPR needs to install different parameters in SETUP.FD
- depending on which version of FrontDoor you're using. In most
- cases, FDRPR is able to detect FD version itself, but in the
- few caes when it is unable to do that, you will have to
- specify either /NEW (for FD 2.12/2.20b or later) or /OLD (for
- FD 2.11, 2.20 or 2.20a).
-
- It's also possible to decide if FD should swap out of memory
- before running FDRPR. This is done by specifying /SWAP or
- /NOSWAP on the FDRPR INSTALL commandline. The default is
- /SWAP.
-
-
- How to use it
- -------------
-
- FDRPR is executed by FrontDoor every time someone requests
- a file. FDRPR needs some parameters to be able to know
- what to do, and FrontDoor is capable of supplying these
- parameters.
-
- The following is a list of the switches that FDRPR
- supports. Switches can start either with a slash (/) or
- with a dash (-). All switches can be shortened to the shortest
- unique name. The switches that accepts a value, can use
- either a colon (:) or a equal character (=) between the
- switch name and the actual value.
-
- /address:<aka> Address of system requesting files
- /bps:<bps> BPS rate of connection
- /check:<filename> Check result of requesting specified file
- /info:<filename> Name of file containing info about
- requesting system. This parameter can be
- specified instead of /address, /bps and
- /operator
- /[un]listed If the system is listed in nodelist or not
- /minutes:<min> Max # of minutes for the file request
- /node:<task> Task number
- /operator:<name> Name of SysOp requesting files
- /request:<filename> Name of file containing requested files
- /[un]secure If the session is password protected or not
- /target:<filename> Name of file where found files should be written
-
- FrontDoor needs to fill in some information in the command
- line, and to do that, it uses the same macros as it does
- for Service Requests. The macros useful for FDRPR is:
-
- =A The requesting system's network address. Eg.
- 2:270/17.
-
- =B The baud rate of the connection. Eg. 9600.
-
- =E Same as =T, but the filename does not include the
- complete PATH.
- (Only available with FD 2.11a / 2.20b or later
- versions).
- This macro is prefered over the =T macro.
-
- =F Name of file containing information about requesting
- system.
-
- =H Number of minutes until next event not allowing
- file requests
-
- =M Same as =F, but the filename does not include the
- complete PATH.
- (Only available with FD 2.11a / 2.20b or later
- versions).
- This macro is prefered over the =F macro.
-
- =O The operator of the requesting system. Eg.
- Bilbo_Baggins.
-
- =Q Same as =R, but the filename does not include the
- complete PATH.
- (Only available with FD 2.11a / 2.20b or later
- versions).
- This macro is prefered over the =R macro.
-
- =R Name of file containing requested files
-
- =T Name of file where found files should be written
-
- =X Whether or not the session is password protected.
- This macro can have two values, SECURE or
- UNSECURE.
-
- =Y The current task number used by FD, or 0 in the
- shareware version.
-
- =W Whether or not the system requesting files is
- listed in your nodelist. This macro can have two
- values, LISTED or UNLISTED.
-
- If the =O macro is used, it should be enclosed with double
- quote characters (") characters to prevent DOS to treat
- some special characters, e.g. < > and |, in a way that would
- prevent FDRPR from working correctly.
-
- This means, that a typical command line to run FDRPR, would
- look like this:
-
- FDRPR /REQUEST:=R /TARGET:=T /=X /INFO:=F /MINUTES:=H
-
- or, to make it shorter:
-
- FDRPR /R:=R /T:=T /=X /I:=F /M:=H
-
- An alternative command line would be:
-
- FDRPR /R:=R /T:=T /=X /A:=A /O:"=O" /B:=B /M:=H
-
- When using FD 2.11a or 2.20b, or later versions, the
- command line aboves should be replaced with:
-
- FDRPR /R:=Q /T:=E /I:=M /=X /M:=H /N:=Y /=W
-
- or
-
- FDRPR /R:=Q /T:=E /=X /A:=A /O:"=O" /B:=B /M:=H /N:=Y /=W
-
- In most cases, one of the lines above would be the one needed,
- and should be entered in
- FDSETUP->Mailer->File Requests->Request Processor->Program
-
- Even if it is possible to specify a fixed # of minutes for
- a file request on the command line, it should be done in
- FDSETUP. FDRPR uses that number in SETUP.FD, the
- possibility to specify a number of minutes on the command
- line should only be used to let FD specify the number of
- minutes left to next event not allowing file requests.
-
-
- FDRPR commands
- --------------
-
- There are a few commands that can be specified when running
- FDRPR to do certain things. The following is a list of
- these commands, and what they do:
-
- CREATE Create list of directories/alias names
- INSTALL Install FDRPR in FrontDoor's setup
- UPDATE Update the list of directories/alias names
-
- The CREATE and UPDATE commands will create the *.RQU, *.RQL and
- *.RQS files from your FD and RA configuration. CREATE always
- creates new files, UPDATE will only create them if any
- of the original file have been updated.
-
- It's not necessary to use CREATE and/or UPDATE. Every time
- FDRPR is run, it will check if it's needed to update these
- files, and if it is, it is done on the fly. But to save
- time for the systems requesting files, it can be a good
- idea to update them manually every time you've changed
- your list of requestable directories, the list with alias
- names, or your RA's file area configuration.
-
-
- Configuration file
- ------------------
-
- The behaviour of FDRPR can also be defined in a
- configuration file. The configuration file should be located
- in the same directory as the .EXE file, and with the same
- basename (i.e. FDRPR if you don't rename it). The extension
- should either be .CFG, or, if you prefer to have one
- configuration file per task, .%TASK%. If the .%TASK% file
- exists, it will always be used. The .CFG file is only used if
- the .%TASK% file doesn't exist.
-
- Many of the switches can either be specified as 'switch' or
- 'noswitch'. The setting is enabled when no isn't used, and
- disabled when no is used.
-
- There are some macros that can be used in the configuration
- file, to make maintainance easier. When using these macros,
- they should begin with the characters dollar ($) and
- left bracket ([) and end with a right bracket (]). E.g.
- The macro CFGDIR should be written as $[CFGDIR]. Besides the
- macros listed below, all environment variables can also be
- used as macros.
-
- The following macros exists:
-
- CfgDir
- This macro translates to the directory where the
- FDRPR.CFG file is located. It can be useful
- when specifying the location of other files.
-
-
-
- The following switches is available in the configuration
- file:
-
- [no]Advert
- If enabled, FDRPR will add a text stating that
- the message was created by FDRPR. It is not
- possible to disable this in the unregistered version.
- Default: Enabled
-
-
- [no]CdRom
- If enabled, FDRPR will use the CD-ROM settings in
- RACONFIG, and have the same kind of CD-ROM support
- that RA has, e.g. to make sure no other line
- currently uses the same device, and then copy the
- requested file to the temporary CD-ROM directory.
- Default: Enabled
-
-
- DataFileDir:<dir>
- If specified, all files created by FDRPR, e.g. the
- *.RQ* files will be created in this directory. By
- default, they are created in the same directory as
- the original list of requestable directories / alias
- names.
-
-
- [no]Descriptions
- If enabled, FDRPR will send a message with file
- descriptions for all successfully requested files.
- Default: Enabled
-
-
- FailMessage:<file>
- File containing a template of the text that should
- be used for the message with the reason for a failed
- request, which is sent to the requesting system.
-
- See below for information about these message
- templates.
-
-
- [no]FormatDescriptions
- If enabled, FDRPR will ignore any newlines found
- in a file description, and wrap the description as
- fits the field best. If disabled, FDRPR will use any
- newlines found in the description, and use them, if
- possible. Descriptions without newlines, or with
- to long lines will still be wrapped by FDRPR.
- Default: Enabled
-
-
- [no]FreeFiles
- If enabled, FDRPR will honor the Free File setting
- for a file or file area, and not perform any limit
- checks for these files.
- Default: Disabled
-
-
- [no]KeepPktFiles
- If enabled, FDRPR will keep all the *.PKT files sent
- to the destination, containing file descriptions,
- and failure reasons.
- Default: Disabled
-
-
- KeyName:<Your name>
- The name your copy of FDRPR has been registered to.
- All messages created by FDRPR will use this name as
- the sender name.
-
-
- KeyNumber:<number>
- Your registration key number, as given to you by the
- registration site.
-
-
- [no]LogFile:<file>
- If this setting is specified as LOGFILE:<file>, log
- information will be written to the specified logfile.
- If NOLOGFILE is specified, no loggin will be performed.
- If neither LOGFILE or NOLOGFILE is specified, log
- information will be written to FD's logfile.
-
- Errors detected during initialization will always be
- written to FD's logfile, ignoring this setting.
-
-
- MaxBaseWildCards:<# of chars>
- The maximal number of allowed wildcards, e.g. ?
- characters, in the base of a requested filename, e.g.
- not including the extension. Before checking this, all
- * characters are converted to the corresponding number
- of ? characters, e.g. XXX*.ARJ is converted to
- XXX?????.ARJ.
- Default is to allow any number of wildcard characters.
- If you specify 5, XXX*.* will be allowed, XX*.* will not.
- but XXX*.* will not be allowed.
-
-
- MaxWildCards:<# of chars>
- The same kind of check as maxbasewildcards does, but
- this switch also counts wildcards in the extension.
- The difference between maxbasewildcards and this
- switch is that allows more flexibility for the user
- requesting files (e.g. if set to 8, it's ok to request
- XX*.X*), but has the disadvantage that it's hard to
- protect against requests like *.GIF.
- See maxbasewildcards for more information.
- Default is to allow any number of wildcard characters.
- If you specify 8, XXX*.* will be allowed, XX*.* will not.
- If you specify 7, XXXX*.* will be allowed, XXX*.X* also,
- but XXX*.* will not be allowed.
-
-
- Message:<file>
- File containing a template of the text that should
- be used for the message with descriptions of the
- successfully requested files, which is sent to
- the requesting system.
-
- See below for information about these message
- templates.
-
-
- [no]MoreTime
- If enabled, FDRPR will request more time from the
- remote mailer, to be able to process the entire
- request, if needed. If this setting is disabled,
- the remote mailer will probably disconnect the line
- if FDRPR requires more then 30 seconds to finish
- the search.
- Default: Enabled
-
-
- [no]PassWordErrors
- If enabled, FDRPR will include all files that should
- have been sent if the correct password was used, in
- the message with the list of failed requests. By
- default, only the requested filename will be included
- in the message.
- Default: Disabled
-
- NOTE! The reason this option is disabled by default, is
- that it could be a security risk to inform
- another system that there is a file available,
- which requires a password.
-
-
- [no]ReportFailures
- If enabled, FDRPR will create a netmail message
- to you with information about failed file requests.
- Default: Disabled
-
-
- ReportMsgBoard:<board>
- The Hudson message board where all report messages
- are created as a result of the ReportRequests and/or
- ReportFailures setting. If neither this setting, nor
- the ReportMsgDir, is specified, these messages are
- created in FrontDoor's netmail directory.
-
-
- ReportMsgDir:<dir>
- The *.MSG directory where all report messages, e.g.
- those messages created as a result of the ReportRequests
- and/or ReportFailures setting. If neither this, nor
- the ReportMsgBoard setting, is specified, these messages
- are created in FrontDoor's netmail directory.
-
-
- [no]ReportRequests
- If enabled, FDRPR will create a netmail message
- to you with information about successful file requests.
- Default: Disabled
-
-
- [no]ResolvePath
- If enabled, FDRPR uses path resolution when trying
- to compare the paths specified in RACONFIG, and the
- paths listed in your list of requestable directories
- and aliasnames. This ensures that FDRPR always
- will be able to match these paths correct.
- However, in some environments, this seems to fail.
- I'm aware of one CD-ROM interface which doesn't
- seem to support this correctly. If you're having
- problems with file areas that are not recognized by
- FDRPR, disable this option.
-
- The resolvepath setting can in some environments
- also slow down the creation of the lists of requestable
- directories/alias names. If this seems to take a long
- time to run, try to specify noresolvepath.
- Default: Disabled
-
-
- UnlistedAlias:<file>
- A file that contains a list of alias names, that unlisted
- systems are allowed to request. By default, unlisted
- systems can request the same alias names that are
- allowed during unsecure sessions, but if this file is
- specified, only these aliases are allowed.
-
-
- UnlistedList:<list>
- A file that contains a list of requestable directories,
- that unlisted systems can request from. By default,
- unlisted systems can request from the same directories
- that area allowed during unsecure sessions, but if this
- file is specified, only the directories listed in it
- is allowed.
-
-
- [no]UnlistedOnlyFree
- If enabled, systems that are unlisted, e.g. doesn't
- exist in the nodelist, nor in the security manager,
- may only request files that either are marked as
- free in RA's file database, or files that exists in
- a file area that are set to only contain free files.
-
-
- [no]UpdCount
- If enabled, FDRPR will update the download counters
- for all successfully requested files
- Default: Enabled
-
-
- WorkDir:<dir>
- The directory where the temporary .PKT files are
- created, before FD sends them to the destination.
- If this parameter is not specified, the .PKT files
- will be written to the directory pointed to by
- the TEMP or TMP environment variable. If neither of
- these environment variables are specified, the .PKT
- file will be written to the root directory of the
- current drive.
-
-
- Message templates
- -----------------
-
- The exact contents and layout of the messages that are sent
- to the requesting system, can be decided by the SysOp. Two
- different messages can be sent; the message containing file
- descriptions for successfully requested files, and the
- message with reasons why a request failed.
-
- Each message should have it's own template, e.g. a file
- describing the format and contents. The names of these files
- are defined in the configuration file.
-
- The template files are just normal textfiles, that can be
- created/edited in any text editor. It's possible to insert
- some unique text in each message, and to do that, a macro
- is used. The exact format of the lines with file descriptions
- and reasons for request failures can also be configured.
-
- When using a macro, it should begin with the characters
- dollar ($) and left bracket ([), and end with a right
- bracket (]). E.g. The macro TOTALSIZE should be written
- as $[TOTALSIZE]. Either lower or upper characters can be
- used, there is no difference between them.
-
- A macro that requires parameters, should have the parameters
- inside the [] characters. Ex: $[Include C:\FD\FILE.TXT].
-
- The following macros exists:
-
- PrgName
- The name of the request processor
-
- Version
- The version of the request processor
-
- YourName
- The full name of the SysOp requesting files
-
- YourFirstName
- The first name of the SysOp requesting files
-
- YourLastName
- The last name of the SysOp requesting files
-
- YourAka
- The address of the requesting system
-
- MyName
- Your name, as defined in FDSETUP
-
- MyFirstName
- Your first name, as defined in FDSETUP
-
- MyLastName
- Your last name, as defined in FDSETUP
-
- MyAka
- Your address. FDRPR will use AKA matching when
- deciding which address should be used
-
- FileCnt
- The number of found files, which will be sent to the
- requesting system
-
- FailCnt
- The number of requests that failed
-
- TotalSize
- The number of bytes that will be sent
-
- TotalSizeK
- The number of kilo bytes that will be sent
-
- Include <file>
- Insert contents of <file> in message
- <file> can also contain macros
-
- Aliases
- Insert list of all alias names that can be requested.
- If the alias file (the one defined in FDSETUP)
- contains comments, these comments will be included in
- this list.
- A comment in the alias file is added at the end of
- a line with an alias name, after a ; character.
-
- IfFile <file1> <file2>
- If <file1> will be sent to the requesting system,
- the contents of <file2> will be added to the message
- that is sent.
- <file1> should only specify the filename, not a drive
- or directory, but can contain wildcard characters.
- <file2> can also contain macros
-
- If a macro is used, that is not in the list above, FDRPR
- will check to see if it is an environment variable, and if it
- is, use it. An example of an environement variable that could
- be useful, is TASK.
-
- Each template should contain ONE line that is used to format
- the file descriptions / request failure reasons. The line
- should start with either a @ or # character. This line can
- contain normal text, or some format codes.
-
- Both @ and # can be used with all formatting codes, the
- difference is that codes beginning with a # character,
- and resulting in a numeric value, will have it's value
- zero padded to the left, while codes beginning with a @
- will not.
-
- The length of each formatting is decided by appending some
- underscore (_) characters after the format code. The length
- of the field will be the total length of the format code,
- and the underscore characters following directly after.
-
- The format codes that are available for the message with
- file descriptions are:
-
- @0 - Empty string. Useful if you don't want the
- line to start with another @ character
- @@ - The character @
- @# - The character #
- @C - The description of the file
- @D - The date of the file
- @F - The name of the file
- @K / #K - The size of the file, in kilobytes
- @N - New line
- @S / #S - The size of the file, in bytes
- @T / #T - The number of downloads for this file
-
- The exact format of the @D code depends on the length of the
- field, and the DOS country setting. The following formats are
- possible:
-
- 10 Sep 1993
- 10 Sep 93
- 10-09-93
- 09-10-93
- 93-09-10
- 100993
- 091093
- 930910
-
- The @N code, New line, will insert a newline character in the
- message, so that the reminding text in the format line will be
- put on the next line of the message. Useful if you want to
- create a multiline description for a file. See below for an
- example.
-
- An example of a formatting line could be:
-
- @F__________ @K__k @D______ [#T] @C_______________________________
-
- Which would result in:
-
- FDRPR121.ARJ 91k 94-09-01 [34] FD Request Processor for RA
-
- Another example could be:
-
- @0File: @F__________@NSize: @K__k@N
- Date: @D_________@NDownloads: #T_@NDescription:
- @C___________________________________________________________@N
-
- (All three lines above, should be one single line, not three
- lines as they have to be written in this document).
-
- The above format line would result in:
-
- File: FDRPR121.ARJ
- Size: 91k
- Date: 1 Sep 1993
- Downloads: 034
- Description: FD Request Processor for RA
-
-
-
- The format codes that are available for the message with
- request failure reasons are:
-
- @F - The name of the requested file
- @R - The reason the request failed
-
-
-
- The lists of requestable directories and alias names
- ----------------------------------------------------
-
- FDRPR will create some files containing information
- about the requestable directories and the alias filenames.
- These files will be stored in the same directory and with
- the same name, as the files specified in FDSETUP, but with
- another extension. The extensions used is .RQS for the files
- used during secure sessions, .RQL for the files used for
- listed system during unsecure sessions, and .RQU for the
- files used for unlisted systems during unsecure sessions.
-
- These files will be maintained automatically by FDRPR,
- and is updated every time the list of requestable
- directories, alias names, or FILES.RA, is modified. It is
- important that these file are not removed, since it is much
- slower to create them every time, then to use them from the
- last run.
-
- IMPORTANT! If your lists of requestable directories or
- list of alias names, uses the .RQS, .RQL or .RQU
- extensions, make sure that you changes this
- to another extension. If you don't rename
- the file, FDRPR will overwrite your list
- with it's own list.
-
-
- If your list with requestable directories contains a
- directory which isn't defined as a file area in RemoteAccess,
- FDRPR will switch over to the same kind of request
- processing as FrontDoor does, e.g. to scan all the files
- in that directory. This makes it possible to have a directory
- with files that should be requestable, but not available from
- the BBS.
-
- If a directory should be available for different types
- of systems, e.g. both unlisted and listed systems, unsecure
- and secure sessions, it's sufficient to specify this
- directory in the file with the lowest security that should
- be allowed to request from it. As an example, a directory
- that should be available for all type of requesting systems,
- only has to be defined in the list of directories for
- unlisted systems.
-
- The files with alias names are handled in the same way, so
- it's sufficient to list alias names that should be available
- for both unsecure and secure sessions in the file for unsecure
- sessions.
-
-
-
- Alias definitions
- -----------------
-
- Normally, an alias definition that uses a wildcard in the
- filename that should be sent, sends all files that matches
- this wildcard name.
-
- If you would prefer that only the newest file matching
- the wildcard name is sent, add a plus (+) character before
- the filename. E.g.
-
- NODELIST C:\FILES\FIDO\NODELIST.A*
-
- could be replaced with
-
- NODELIST +C:\FILES\FIDO\NODELIST.A*
-
-
- An other variant of the alias definition, is to send the
- contents of the matching file(s) as a netmail message,
- instead of a file. FDRPR will read the file as it does
- with a message template file, expand any macros that
- exists in it, and send the result as a netmail to the
- requesting person.
-
- To do this, you add a colon (:) character before the
- filename. E.g.
-
- ABOUT :C:\FILES\ABOUT.TXT
-
- Each matching file will be sent as a single message.
-
- The plus (+) character is also supported, to send only
- the latest file if more then one file matches the file
- specification. E.g.
-
- NEWBULLETIN +:C:\FILES\BULLETIN.*
-
-
- Another character that can be added in front of the filename,
- is a slash (/) character. A file with the slash character in
- front of it will be considered as a free file, and will not be
- counted, when the limits of how much a node may request are
- checked. E.g.
-
- FREEFILE /C:\FILES\FREEFILE.TXT
-
- For this to work, you also have to define 'FreeFiles' in your
- configuration file.
-
-
-
- Use FDRPR to test file requests locally
- -----------------------------------------
-
- FDRPR could be used to check a file request locally, to
- get some information why a certain file request fails, or
- just to test your setup.
-
- To run FDRPR like this, enter the following command:
-
- FDRPR /CHECK:<file>
-
- To test a file request that requires a password, use the
- following command:
-
- FDRPR /CHECK:"<file> !<password>"
-
- To test more then one file request at the same time, use the
- following command:
-
- FDRPR /CHECK:"<file1> [!<pwd1>],<file2> [!<pwd2>][,...]"
-
- To make the request more realistic, you can also add any of
- the other switches. But the only switches that would make
- any difference, is the /SECURE and the /BPS:<bps> switches,
- and the /ADDRESS switch, which would have FDRPR create the
- PKT file it should have sent to the requesting system.
-
-
-
- Legal notice
- ------------
-
- FDRPR is provided to you as is, without warranty of any
- kind. In no event shall Mats Wallin be liable to you or
- anyone else for any damages or costs arising from the use
- or inability to use this program.
-
- FDRPR is protected by copyright laws, and may not be
- modified, reversed engineered, sold or distributed in any
- way that would involve some sort of trade, without written
- permission from Mats Wallin.
-
- FrontDoor is a registered trademark of Joaquim Homrighausen.
-
- All other brand or product names are trademarks or registered
- trademarks of their respective holder.
-
-
- Registering
- -----------
-
- FDRPR may be used during a 30 day trial period to allow
- you to determine its suitability for your particular
- application. After this trial period you must register
- the program, if you are continuing to use it.
-
- Please see the file REGINFO.TXT for information on
- how to register FDRPR.
-
-
- Bug reports, suggestions, etc.
- ------------------------------
-
- If you find any bugs, or have suggestions or comments on
- this program, I would appreciate if you would let me know.
- Send the information to me at:
-
- 2:270/19@fidonet or mw@abslu
-