nydel/muclr

multi-user common lisp repl

muclr's Issues

registrar web-based interface development

we'll use hunchentoot for the time being. this is a huge project on its own.

spec

will be useful to have a specification for how a server communicatees with a registrar.

and perhaps also for how a client communicates with a server.

client-to-server API standard

see wiki for this as it develops.

organize repeated code especially clos definitions

probably need to restructure the filesystem as well. this is high priority. the more work we get done, the sloppier it becomes. unless we periodically clean things up.

initial project planning

obviously this project is just beginning to be born. i'll need to put together the bones or at least their blueprints before anything else can be done.

assembling a team

multi-user common lisp repl, as a system/project, will take a lot of different specialized skillsets to execute properly. once the first steps are taken in organizing it as a project, the next step will be to pitch the idea to programmers who may be interested in making muclr a functioning reality.

domain registration and setup

for the registrar and for other purposes including maximizing efficiency of development and establishing project legitimacy, we must find a home on the internet.

server recode featuring CLOS

boy oh boy. muclr/src/server.lisp for the damage. the class "muclr-listener" is nuts. but we're going to have tons of fun threading each connecting instance on the server end as a parallel process. this will give us a way to really f'cking streamline the specific handling of separate users/connections by - 1) making each connection a separate object - 2) including and making accessible each connection & its user's details inside the object - 3) cycling through the objects in order to process everything in realtime like some crazy epileptic repl listening to death metal in front of a strobe light.

everyone who has heard i'm doing this and not signed on yet is an idiot. this is the most fun project imaginable.

license application

will need to decide on or design a license for the project.

packages for API

we'll start with a canonical API then add an easy-to-use non-canonical expansion file complete with simple example and documentation.

muclr-server connection class object

let's define this in a separate file and package and have :muclr-server depend-on that package.