Added missing files

git-svn-id: http://svn.dmdirc.com/trunk@7 00569f92-eb28-0410-84fd-f71c24880f

dist/README.TXT

@@ -0,0 +1,31 @@
+========================
+BUILD OUTPUT DESCRIPTION
+========================
+
+When you build an Java application project that has a main class, the IDE
+automatically copies all of the JAR
+files on the projects classpath to your projects dist/lib folder. The IDE
+also adds each of the JAR files to the Class-Path element in the application
+JAR files manifest file (MANIFEST.MF).
+
+To run the project from the command line, go to the dist folder and
+type the following:
+
+java -jar "DMDirc.jar" 
+
+To distribute this project, zip up the dist folder (including the lib folder)
+and distribute the ZIP file.
+
+Notes:
+
+* If two JAR files on the project classpath have the same name, only the first
+JAR file is copied to the lib folder.
+* If the classpath contains a folder of classes or resources, none of the
+classpath elements are copied to the dist folder.
+* If a library on the projects classpath also has a Class-Path element
+specified in the manifest,the content of the Class-Path element has to be on
+the projects runtime path.
+* To set a main class in a standard Java project, right-click the project node
+in the Projects window and choose Properties. Then click Run and enter the
+class name in the Main Class field. Alternatively, you can manually type the
+class name in the manifest Main-Class element.

docs/rfcs/RFC2810.txt

@@ -0,0 +1,561 @@
+
+
+
+
+Network Working Group                                           C. Kalt
+Request for Comments: 2810                                   April 2000
+Updates: 1459
+Category: Informational
+
+
+                   Internet Relay Chat: Architecture
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   The IRC (Internet Relay Chat) protocol is for use with text based
+   conferencing. It has been developed since 1989 when it was originally
+   implemented as a mean for users on a BBS to chat amongst themselves.
+
+   First formally documented in May 1993 by RFC 1459 [IRC], the protocol
+   has kept evolving. This document is an update describing the
+   architecture of the current IRC protocol and the role of its
+   different components.  Other documents describe in detail the
+   protocol used between the various components defined here.
+
+Table of Contents
+
+   1.  Introduction ...............................................   2
+   2.  Components .................................................   2
+      2.1  Servers ................................................   2
+      2.2  Clients ................................................   3
+         2.2.1  User Clients ......................................   3
+         2.2.2  Service Clients ...................................   3
+   3.  Architecture ...............................................   3
+   4.  IRC Protocol Services ......................................   4
+      4.1  Client Locator .........................................   4
+      4.2  Message Relaying .......................................   4
+      4.3  Channel Hosting And Management .........................   4
+   5.  IRC Concepts ...............................................   4
+      5.1  One-To-One Communication ...............................   5
+      5.2  One-To-Many ............................................   5
+         5.2.1  To A Channel ......................................   5
+         5.2.2  To A Host/Server Mask .............................   6
+
+
+
+Kalt                         Informational                      [Page 1]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+         5.2.3  To A List .........................................   6
+      5.3  One-To-All .............................................   6
+         5.3.1  Client-to-Client ..................................   6
+         5.3.2  Client-to-Server ..................................   7
+         5.3.3  Server-to-Server ..................................   7
+   6.  Current Problems ...........................................   7
+      6.1  Scalability ............................................   7
+      6.2  Reliability ............................................   7
+      6.3  Network Congestion .....................................   7
+      6.4  Privacy ................................................   8
+   7.  Security Considerations ....................................   8
+   8.  Current Support And Availability ...........................   8
+   9.  Acknowledgements ...........................................   8
+   10.  References ................................................   8
+   11.  Author's Address ..........................................   9
+   12.  Full Copyright Statement ..................................  10
+
+1. Introduction
+
+   The IRC (Internet Relay Chat) protocol has been designed over a
+   number of years for use with text based conferencing.  This document
+   describes its current architecture.
+
+   The IRC Protocol is based on the client-server model, and is well
+   suited to running on many machines in a distributed fashion.  A
+   typical setup involves a single process (the server) forming a
+   central point for clients (or other servers) to connect to,
+   performing the required message delivery/multiplexing and other
+   functions.
+
+   This distributed model, which requires each server to have a copy
+   of the global state information, is still the most flagrant problem
+   of the protocol as it is a serious handicap, which limits the maximum
+   size a network can reach.  If the existing networks have been able to
+   keep growing at an incredible pace, we must thank hardware
+   manufacturers for giving us ever more powerful systems.
+
+2. Components
+
+   The following paragraphs define the basic components of the IRC
+   protocol.
+
+2.1 Servers
+
+   The server forms the backbone of IRC as it is the only component
+   of the protocol which is able to link all the other components
+   together: it provides a point to which clients may connect to talk to
+
+
+
+
+Kalt                         Informational                      [Page 2]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+   each other [IRC-CLIENT], and a point for other servers to connect to
+   [IRC-SERVER].  The server is also responsible for providing the basic
+   services defined by the IRC protocol.
+
+2.2 Clients
+
+   A client is anything connecting to a server that is not another
+   server.  There are two types of clients which both serve a different
+   purpose.
+
+2.2.1 User Clients
+
+   User clients are generally programs providing a text based
+   interface that is used to communicate interactively via IRC.  This
+   particular type of clients is often referred as "users".
+
+2.2.2 Service Clients
+
+   Unlike users, service clients are not intended to be used manually
+   nor for talking.  They have a more limited access to the chat
+   functions of the protocol, while optionally having access to more
+   private data from the servers.
+
+   Services are typically automatons used to provide some kind of
+   service (not necessarily related to IRC itself) to users.  An example
+   is a service collecting statistics about the origin of users
+   connected on the IRC network.
+
+3. Architecture
+
+   An IRC network is defined by a group of servers connected to each
+   other.  A single server forms the simplest IRC network.
+
+   The only network configuration allowed for IRC servers is that of
+   a spanning tree where each server acts as a central node for the rest
+   of the network it sees.
+
+                       1--\
+                           A        D---4
+                       2--/ \      /
+                             B----C
+                            /      \
+                           3        E
+
+   Servers: A, B, C, D, E         Clients: 1, 2, 3, 4
+
+                    [ Fig. 1. Sample small IRC network ]
+
+
+
+
+Kalt                         Informational                      [Page 3]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+   The IRC protocol provides no mean for two clients to directly
+   communicate.  All communication between clients is relayed by the
+   server(s).
+
+4. IRC Protocol Services
+
+   This section describes the services offered by the IRC protocol.  The
+   combination of these services allow real-time conferencing.
+
+4.1 Client Locator
+
+   To be able to exchange messages, two clients must be able to locate
+   each other.
+
+   Upon connecting to a server, a client registers using a label which
+   is then used by other servers and clients to know where the client is
+   located.  Servers are responsible for keeping track of all the labels
+   being used.
+
+4.2 Message Relaying
+
+   The IRC protocol provides no mean for two clients to directly
+   communicate.  All communication between clients is relayed by the
+   server(s).
+
+4.3 Channel Hosting And Management
+
+   A channel is a named group of one or more users which will all
+   receive messages addressed to that channel.  A channel is
+   characterized by its name and current members, it also has a set of
+   properties which can be manipulated by (some of) its members.
+
+   Channels provide a mean for a message to be sent to several clients.
+   Servers host channels, providing the necessary message multiplexing.
+   Servers are also responsible for managing channels by keeping track
+   of the channel members.  The exact role of servers is defined in
+   "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+5. IRC Concepts
+
+   This section is devoted to describing the actual concepts behind the
+   organization of the IRC protocol and how different classes of
+   messages are delivered.
+
+
+
+
+
+
+
+
+Kalt                         Informational                      [Page 4]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+5.1 One-To-One Communication
+
+   Communication on a one-to-one basis is usually performed by clients,
+   since most server-server traffic is not a result of servers talking
+   only to each other.  To provide a means for clients to talk to each
+   other, it is REQUIRED that all servers be able to send a message in
+   exactly one direction along the spanning tree in order to reach any
+   client.  Thus the path of a message being delivered is the shortest
+   path between any two points on the spanning tree.
+
+   The following examples all refer to Figure 1 above.
+
+   Example 1: A message between clients 1 and 2 is only seen by server
+       A, which sends it straight to client 2.
+
+   Example 2: A message between clients 1 and 3 is seen by servers A &
+       B, and client 3.  No other clients or servers are allowed see the
+       message.
+
+   Example 3: A message between clients 2 and 4 is seen by servers A, B,
+       C & D and client 4 only.
+
+5.2 One-To-Many
+
+   The main goal of IRC is to provide a forum which allows easy and
+   efficient conferencing (one to many conversations).  IRC offers
+   several means to achieve this, each serving its own purpose.
+
+5.2.1 To A Channel
+
+   In IRC the channel has a role equivalent to that of the multicast
+   group; their existence is dynamic and the actual conversation carried
+   out on a channel MUST only be sent to servers which are supporting
+   users on a given channel.  Moreover, the message SHALL only be sent
+   once to every local link as each server is responsible to fan the
+   original message to ensure that it will reach all the recipients.
+
+   The following examples all refer to Figure 2.
+
+   Example 4: Any channel with 1 client in it. Messages to the channel
+       go to the server and then nowhere else.
+
+   Example 5: 2 clients in a channel. All messages traverse a path as if
+       they were private messages between the two clients outside a
+       channel.
+
+
+
+
+
+
+Kalt                         Informational                      [Page 5]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+   Example 6: Clients 1, 2 and 3 in a channel.  All messages to the
+       channel are sent to all clients and only those servers which must
+       be traversed by the message if it were a private message to a
+       single client.  If client 1 sends a message, it goes back to
+       client 2 and then via server B to client 3.
+
+5.2.2 To A Host/Server Mask
+
+   To provide with some mechanism to send messages to a large body of
+   related users, host and server mask messages are available.  These
+   messages are sent to users whose host or server information match
+   that of the mask.  The messages are only sent to locations where
+   users are, in a fashion similar to that of channels.
+
+5.2.3 To A List
+
+   The least efficient style of one-to-many conversation is through
+   clients talking to a 'list' of targets (client, channel, mask).  How
+   this is done is almost self explanatory: the client gives a list of
+   destinations to which the message is to be delivered and the server
+   breaks it up and dispatches a separate copy of the message to each
+   given destination.
+
+   This is not as efficient as using a channel since the destination
+   list MAY be broken up and the dispatch sent without checking to make
+   sure duplicates aren't sent down each path.
+
+5.3 One-To-All
+
+   The one-to-all type of message is better described as a broadcast
+   message, sent to all clients or servers or both.  On a large network
+   of users and servers, a single message can result in a lot of traffic
+   being sent over the network in an effort to reach all of the desired
+   destinations.
+
+   For some class of messages, there is no option but to broadcast it to
+   all servers so that the state information held by each server is
+   consistent between servers.
+
+5.3.1 Client-to-Client
+
+   There is no class of message which, from a single message, results in
+   a message being sent to every other client.
+
+
+
+
+
+
+
+
+Kalt                         Informational                      [Page 6]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+5.3.2 Client-to-Server
+
+   Most of the commands which result in a change of state information
+   (such as channel membership, channel mode, user status, etc.) MUST be
+   sent to all servers by default, and this distribution SHALL NOT be
+   changed by the client.
+
+5.3.3 Server-to-Server
+
+   While most messages between servers are distributed to all 'other'
+   servers, this is only required for any message that affects a user,
+   channel or server.  Since these are the basic items found in IRC,
+   nearly all messages originating from a server are broadcast to all
+   other connected servers.
+
+6. Current Problems
+
+   There are a number of recognized problems with this protocol, this
+   section only addresses the problems related to the architecture of
+   the protocol.
+
+6.1 Scalability
+
+   It is widely recognized that this protocol does not scale
+   sufficiently well when used in a large arena.  The main problem comes
+   from the requirement that all servers know about all other servers,
+   clients and channels and that information regarding them be updated
+   as soon as it changes.
+
+6.2 Reliability
+
+   As the only network configuration allowed for IRC servers is that of
+   a spanning tree, each link between two servers is an obvious and
+   quite serious point of failure.  This particular issue is addressed
+   more in detail in "Internet Relay Chat: Server Protocol" [IRC-
+   SERVER].
+
+6.3 Network Congestion
+
+   Another problem related to the scalability and reliability issues, as
+   well as the spanning tree architecture, is that the protocol and
+   architecture for IRC are extremely vulnerable to network congestions.
+   This problem is endemic, and should be solved for the next
+   generation: if congestion and high traffic volume cause a link
+   between two servers to fail, not only this failure generates more
+   network traffic, but the reconnection (eventually elsewhere) of two
+   servers also generates more traffic.
+
+
+
+
+Kalt                         Informational                      [Page 7]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+   In an attempt to minimize the impact of these problems, it is
+   strongly RECOMMENDED that servers do not automatically try to
+   reconnect too fast, in order to avoid aggravating the situation.
+
+6.4 Privacy
+
+   Besides not scaling well, the fact that servers need to know all
+   information about other entities, the issue of privacy is also a
+   concern. This is in particular true for channels, as the related
+   information is quite a lot more revealing than whether a user is
+   online or not.
+
+7. Security Considerations
+
+   Asides from the privacy concerns mentioned in section 6.4 (Privacy),
+   security is believed to be irrelevant to this document.
+
+8. Current Support And Availability
+
+        Mailing lists for IRC related discussion:
+          General discussion: ircd-users@irc.org
+          Protocol development: ircd-dev@irc.org
+
+        Software implementations:
+          ftp://ftp.irc.org/irc/server
+          ftp://ftp.funet.fi/pub/unix/irc
+          ftp://coombs.anu.edu.au/pub/irc
+
+        Newsgroup: alt.irc
+
+9. Acknowledgements
+
+   Parts of this document were copied from the RFC 1459 [IRC] which
+   first formally documented the IRC Protocol.  It has also benefited
+   from many rounds of review and comments.  In particular, the
+   following people have made significant contributions to this
+   document:
+
+   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
+   Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                      [Page 8]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+10. References
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
+                Protocol", RFC 1459, May 1993.
+
+   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+                2812, April 2000.
+
+   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+                2813, April 2000.
+
+   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
+                2811, April 2000.
+
+11. Author's Address
+
+   Christophe Kalt
+   99 Teaneck Rd, Apt #117
+   Ridgefield Park, NJ 07660
+   USA
+
+   EMail: kalt@stealth.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                      [Page 9]
+
+RFC 2810           Internet Relay Chat: Architecture          April 2000
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 10]
+

nbproject/private/private.properties

@@ -0,0 +1,4 @@
+application.args=
+javac.debug=true
+javadoc.preview=true
+user.properties.file=/home/chris/.netbeans/5.5/build.properties

nbproject/private/private.xml

@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project-private xmlns="http://www.netbeans.org/ns/project-private/1">
+    <editor-bookmarks xmlns="http://www.netbeans.org/ns/editor-bookmarks/1"/>
+</project-private>