Maarten van Hoof
At this time, a number of people are doing a number of different things to NFC:
- Ruben Carcia is building an all-htlm interface to the server. He is building a client that does not rely on Java or Flash or anything installed on the client.
- Jonathan Ellis is working on a bare-bones applet client. His idea is to build a client that is much simpler than the two existing clients and loads faster. He's working on a number of othr things, but I'm sure he'll tell you himself.
- I am on bug hunting and answering questions on the forums. I have immediate plans on improving the manual and lots of other plans that I do not expect to have time for in the near future. The most important one being porting NCF to java 1.4 nio.
I would like to invite both Jonathan and Ruben (and all other NFC developers and anybody who has any ideas) to post their personal todo list here and tell us a little more about how they are going about their projects. That way we can benifit from each others experience, coordinate our efforts a little and we will be documenting our desing rationale as we go along. I'll start with my own todo list:
- Write a manual. This is the first item on my list because I believe it is more important than anything else. More javadoc would be good, but the real problem is that we lack good documentation on how to use NFC. We shouldn't be writing NFC for other java developers, we should be writing it for people how want to offer chat functionality to their community. Answering questions on the forums has tought me that a lot of people find NFC very hard to use.
- Port the whole communication layer to JDK1.4 nio. Currently, every user on the server is one thread. This obviously limits the amount of users that can log in. Using java.nio, we can iliminate this limitation. My idea is to rewrite the CommandProcessorRemote so that it performs commands on a thread from a thread pool. ConnectionHandler would also have to be rewritten.
- Implement server distribution on another JMS implementation. We have been using SwiftMQ until now, but that is no longer free. I am thinking about openJMS myself, but any suggestions are welcome.
- Create a ClientProxy object that serves as a proxy to a ChatClient object on a different server. This would help solve some issues related to server distribution, like the fact that you do not know a client's access level or ignored users if that client is not logged in to the machine that you are processing a command on.
- Write a very handsome client. NFC users will never see anything else! But since two people are working on clients now, this has moved to the bottom of my list.
This is not just an invitation to Ruben and Jonathan to tell us what they are doing and how they are doing it, it is also a call to everybody to spell their guts and tell us what you think would be good for NFC.
I'm looking forward to your comments.
as Maarten says, the first thing I'm working on is a lightweight java client. Next I have a list of features intended to work in connection with an SQL database but alternate storage methods (config files) could be supported:
* permanent (until disabled) ignore
* display hints to client for usernames (italics, prefix, postfix, etc.) This would require an addition to the protocol, either as an additional command or an enhancement of exisitings ones.
* control over what channels are allowed to be created, who can become an op in them, etc.
I must have come up with a poor term for this b/c nobody understands what I mean at first. :0
I'm thinking an optional extension to the protocol is the way to go here; it will be more efficient than having clients send a /userflags <name> for each user. So if the client sends "/signon user pass enhanced", server will know it can use these. So /who would result in something like
/who <flag>GlobalOp</flag>jonathan <flag>ChannelOp</flag>todd <flag>Ignored</flag>carl
clients who do not use enhanced signon will simply receive
/who jonathan todd carl
Maarten van Hoof
Have you considered using the /version command for this? All clients send their version after login, and you could use the version label to determine whether a client understands enhanced syntax. That sort of thing is probably exactly what it is there for!
... and have almost finished ;)
sorry that i hadn't answered yet
what am i doing...
the nfc chat doesn't support users without java or flash installed on their system and because neither is a standard at the moment i'm implementing the html only version
what does this mean?
Html doesn't have the ability to present such dynamic contant as it would have to deal with a chat
http also isn't intended as a protocol with continous connections
so there is no posibillity to manage a pure html/http client
the original com.lirysoft.chat.server.remote.ChatServer can't handle clients that communicate completely per http/html
so... what should i do?
my idea: http has a well known bug which often has been used to implement chats! short description of the bug: build a response with a non closing connection and send everything, like an email or real big html page, as a multipart/mixed instead of text/html
the benefit is obvious: neither the client nor the server pretend to close the connection untill you explicitely want to!
ok that is it for the real client side...
the server side had to be changed...
because the named ChatServer lacks of some features needed to handle HtmlChatClients i made my own
now my current problems:
the communication between the real client and the server is based on four jsp where one builds the frame, one gets the input, another one sends it back to the server and the last displays the output
so the whole program logic has to be situated in the chatserver and there is te problem: to stay conform with the original i have to implement both the serverside commands and the clientside commands by now i am not sure where to put the clientcommandprocessing
but everything else... works fine ;))
another feature will be the parsing of the user input for emoticons etc. but maarten already showed me a way to manage this in a handsome way thx btw ;))
ok i'll continue with the commandprocessing
and i'll tell you what i've done
This sounds fascinating, but I am not sure I understand what you are talking about. First of all, are you building on an actual bug that exists in some or maybe even all HTTP implementations or are you building on a little-known feature of the HTTP protocol? Can you point me somewhere wher I can read more about this?
Second, where are your jsp pages located? Is client's browser connected to the NFC server directly or is it connected to something like a servlet container? If so, than the servlet container should do the client side processing and the NFC server can remain unchanged.