lilyCore Client Options

In the old days, #$# client name version was used by clients get the features they want from the server, for example %recip_regexp. This created a real problem for new clients connecting to older servers: the server had to know your client's name in advance. As a result, some clients simply masqueraded as a client with the features they desired.

#$# options was created to eliminate this problem, by allowing a client to add and remove options at any time. At any point after the client is connected to the server, it can send #$# options ... to the server to register its options. This event extends to transmitting before the login prompt has been replied to. As a test, simply telnet to the server, and at the login prompt do #$# options. Whenever you set options the server will reply to you with %options followed by +optionname for options successfully or currently enabled, and -optionname for those options unsupported by this server.

To indicate support for an option use +optionname to remove support use -optionname.

Available Options

The order of the options described below is based on their time of creation. This is preserved to give a sense of the relationship between deprecated elements.

recip

Turns on the transmission of the %recip
This option is deprecated in favor of client-local parsing with tools like %recip_regexp
 

sender

Turns on the transmission of %sender
 

sendgroup

Turns on the transmission of %sendgroup
 

recip_regexp

If requested before login is complete, it causes %recip_regexp to be transmitted near the end of the login process. Any other time this option is requested, it causes %recip_regexp to be transmitted immediately in response.
 

connected

This causes %connnected to be transmitted on the completion of the login process. If this command arrives after login has completed, it is ignored.
 

info_size

If requested before login is complete, it causes %info_size to be transmitted near the end of the login process. Any other time this option is requested, it causes %info_size to be transmitted immediately in response.
 

usertype

If requested before login is complete, it causes %user_type to be transmitted near the end of the login process. Any other time this option is requested, it causes %user_type to be transmitted immediately in response.
 

leaf-msg

This causes messages to be bracketted with %beginmsg and %endmsg These data transmitted between these markers is not atomic or labeled, and as such can be easily the victim of interleaving. This weakness is one of the issues which gave rise to the development of SimpleLilyClientProtocol. (As a historical note, this feature was built to be similar to what XCONNECT used to parse CONNECT's messaging output.)
 

leaf-cmd

Transforms all lily output into label segments, which allows for input to be uniquely tied to output. See %begin, %command, and %end. This option is entirely compatible with the slcp option. When leaf-cmd is enabled the token "COMMAND=id" will be added to any SLCP events.
 

leaf-notify

This is the original name for what turn into the SimpleLilyClientProtocol. While this should be the same as the newer slcp option, some of the more recent code in the server will check for slcp and not for leaf-notify. Also, setting the slcp option will automatically turn on the leaf-notify option. Thus, it would probably be best for clients to turn on the slcp or slcp-name options instead of only setting this original option name.

slcp

This option was added as a replacement for leaf-notify, since the title 'leaf' has lost context with all but a few lily client developers. If this option is enabled prior to login, then an SLCP synchronization block will be sent prior to the completion of the login process. If you enable the option afterward, no such block is sent. In that case it is advisable to make use of the client command: "#$# slcp-sync". For best results, any clients using slcp or slcp-name should also plan on using the prompt and prompt2 options.   NOTE: as of lilyCore 2.8 it is still not possible to register for SLCP after the login prompt. If this limitation is changed the documentation will be updated, but any client which wanted that ability to switch into SLCP after login would need to be aware of the server revision anyway.
 

prompt

This results in the server transmitting special %prompt messages, instead of just sending a line without a closing newline character when the server wants the client to use some special prompt for the next line it reads from the user.
 

leaf-all

This option is being phased out, please discontinue its use. If you desire the same functionality then issue the statement: #$# options +leaf-cmd +leaf-msg. This option has nothing at all to do with SLCP.
 

whoami

This option sets a flag for text mode clients, requesting a %whoami message whenever the name, blurb, or state of the user changes. Some more advanced text mode clients, like clily use this to maintain an active title bar in their window.
 

prompt2

Supplements the feature provided by %prompt by sending a %prompt2 message whenever file-oriented input is required (e.g. /INFO). This was implemented as a separate option to prevent existing clients, which often use the %prompt command, from breaking. See also the server message %prompt2. If a client has both the prompt and prompt2 options set, it should be true that it will never receive a "partial line" (one without a closing newline character) as a prompt from the server. This makes it easier to reliably-parse any of the ServerMessages which may be sent to the client.
 

version

Immediately sends the version number of the server instance, please see the server message %server
 

slcpjr

This option has been deprecated in favor of slcp-name.
 

jabber

If you are interested in the jabber protocol, please speak to a server developer about it. The jabber support in the server was preliminary, and is almost certainly way out-of-date with any recent standard of the jabber protocols.
 

slcp-name

The idea of slcp-name is basically to send all information to the client via the same server-messages that the original slcp feature would, except to use plain names instead of object numbers. Thus, the client does not need to mirror the database of all the moo-objects that the server knows about. Thus the client does not need to keep "in sync" with the server. This feature is still under development. If you are interested in the SLCP-name protocol, please speak to a server developer about it (probably Garance, since this feature was proposed to benefit clily development).
 

tcpnodelay

Disables the Nagle algorithm for this particular connection. This feature should only be used for $TRANSFER-like connections, as the algorithm is designed to conserve bandwidth in telnet-like connections by aggregating data on the client end before transmission. This will give you a HUGE performance increase for $TRANSFER-like operations, but will probably slow you down in most standard situations.   This option was added by Garance to lilyCore-2.6.2
 

bell

When this option is on, the server will send %g prefixes on any line where the user is expecting a "beep" (/signal).   NOTE:  This option is different from most other options, in that it is now usually on by default. (Older versions of the server had a build-in list of which clients wanted it on, and which clients wanted it off). If anything, a client would be more likely specify the -bell option to turn this processing off. Also note that slcp handles "bells" via a much better method, such that the special %g prefixes will never be sent to a client which has turned on the slcp or slcp-name options.   Note: While this option has been documented in various places, it looks like it was never implemented on the server. I do plan to add it sometime, though.
 

Example

Welcome to lilyCore release 2.2

login: #$# options +sender +sendgroup +recip_regexp +blat
%options -blat +sender +sendgroup +recip_regexp  

If you wanted to turn leafing on:

#$# options +leaf-all

Then turn it off:

#$# options -leaf-all

Keep in mind the user is working through the login process while all of this is going on. If you don't turn on the connected option quickly you may get past that point in the login process.

Revision 4, 24 September 2001, Webmaster

Revision 5, 22 September 2002, DD

Revision 6, 7 October 2002, CAR [PR#385, PR#429, PR#478]

to top