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.
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
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. www.your-domain.com:8080/nfc/tunnel. 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 (rooms.staticrooms=...)
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.
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... ;-)