server modifications for nfc flash chat client for nfc phpSorm - PHP Simple Object Relational Mapping

server modifications - nfcchat

UPDATE 29.Jun.04: I am sorry! I accidently did not include the source-tree in the download, and nobody asked me for that. I noticed this today and repackaged the nfc server. The download now includes everything, source and binaries.

UPDATE 18.Nov.03: I finally implemented HTTP-Tunneling for the Flash-Client! In the past this was only possible with the java-client. Now you can use the flash-client even if you are behind a firewall. The new client can be found in web/flash2 in the source package or in nfc/flash2 after deploying the nfc.war to an application-server.

UPDATE 15.Sept.03: This is a new version which can handle flash- and java-clients at the same time by auto-sensing which client connects. This also fixes a bug from my last version where static rooms where accidently closed.

I have made some modifications to the marvellous chatserver nfcchat. I hope that these changes will be integrated into nfcchat after they have been reviewed, so this page is only temporary.

Download: You can download the complete nfc-package here:
Download as ZIP (2.2MB) | Download as tar.gz (1.8MB)

The files are based on the current (6. Aug. 03) release-candidate 1.1.0-rc1 and by default behave in the same way as the unpatched server.

If you have any comments, feel free to contact me:

The additional features are:


You do not have to make any configuration changes to use this feature. The http-enabled flash-client resides in the /web/flash2 directory or in /nfc/flash2 after deploying the nfc.war to your app-server.

The http-tunneling is implemented in nfcHttpEngine.swf, which is based on the original engine by ajdigital (now stored as nfcSocketEngine.swf in flash2). The http-engine uses exactly the same interface as the original socket-engine. So it should be possible to make ANY nfc-flashclient http-aware by simply exchanging the nfcEngine.swf against nfcHttpEngine.swf.

The new flash-client in the directory flash2 uses both socket- and http-communication. It first tries to establish a socket-connection. If this fails three times it loads the httpEngine and tries to connect to the servlet-tunnel.

The additional parameter required for the http-tunnel is _servlet=... (given in the query-string for the flash-movie). This must be the url to nfc's tunnel-servlet, e.g. See flash2/nfcFlash.html for an example on how to embed the flash-movie in your html. _httpOnly=1 can be used to use only the http-tunnel and not try the socket first. For details on the parameters which the flash-client generally accepts, see flash chat-client for nfc.

static rooms
In nfc.conf just add the names of your rooms in rooms.staticrooms. This is a list of roomnames which by default is seperated by a tab (if you must use a tab in the room-name itself for any case you can chage the delimiter in rooms.staticrooms.delimiter). So to auto-create two chat-rooms "General Recipes" and "Banana Pies" you would use:
      rooms.staticrooms=General Recipes<press tab here>Banana Pies
IMPORTANT: I don't know whether the static rooms do work in combination with the distributed JMS-chat. I could not check this yet.
Note: It should be easy to add a command for operators to make a room static on runtime.

client auto-sensing

nfcchat can handle flash-clients (which use an simple xml-protocol with different line-endings) and the "classic" java-or-whatever-client (simple lines with tab-delimited arguments). The different protocols are handled by different ChatClient- and ConnectionHandler-classes which are created by the ChatServer/FlashChatServer.
I added a factory for ChatClient and some auto-sensing which can determine the client type based on the first characters which are sent.
Both flash- and java-clients can now be served at the same time and can even communicate with each other. The client type does not make a difference any more.
Note: if you want to add new clients, then you should implement IChatClientFactory/extend ChatClientFactory and set your own factory in nfc.conf as chatClientFactory.class=... .

When a user creates a new room he is automatically promoted to an operator in this room by default, so that he can kick and ban users. As this is not always the desired behaviour i made this configurable in nfc.conf, too. You can use rooms.autoPromote = false to turn off this behaviour. Of course you need another way to promote users to operators in this case. This option is mainly useful with a custom authenticator, which e.g. checks the username against a database to determine whether the user should be an operator (and this feature was necessary to implement the static rooms).

I hope someone else has use for these features too... ;-)