Report about the MOO-Library Project

All work was done by Hanspeter Heeb. I got some hints from Chris Müller how to set up a local MOO-Server. I choose to work networked to the Internet, because I estimated to loose some fore to eight extra hours on setting up an other database and transferring the final result.

Defining Objects

This part worked out well. Nevertheless it is some what difficult to define objects without having a clear idea of strength and weaknesses of the program you use afterwards. Defining new objects features and revising existing objects should more be done in parallel. I choose first to define objects features hoping that I would still get the book about the enCore MOO-Database.

I had to revise my definition twice. The problem was the handling of the lists of logical and physical media. I first thought of having one object for each logical media (entries for a book for instance) and a container as book-shelf. Then I saw that there is some database object and decided to use this. Later I realised that data entry in the MOO for any list is not feasible for the planed library system.

The user should be presented all fields with the actual entry and be prompted to change any field. He could enter line by line without line number or specific lines with a leading line-number. Also there should be a undo for all changes and for the last change.

  Description 1: 

      Authors 2: 

Abstract-Link 3: 

Abstract-Link 4: 

Readabilityratings enter -4, -2, 0, 2, 4")

      Overall 5: 

 Easy to read 6: 

    Organised 7: 

        Brief 8: 

Vievy, Humour 9: 

Quality of content ratings enter -4, -2, 0, 2, 4")

   Erroneous 10:

    Complete 11:

   Actuality 12:

GenReference 13:

Obviously this is not user friendly. So I decided to make a Generic Data Table and program export and import. Both should be done in the tab-tab-return format, so that the user can copy and paste them between the MOO and a database or spreadsheet-application.

Checking for objects with similar properties and verbs

There are 60 objects of the Lambda-Core-Database and 77 additional objects for the enCore-Database. Totalling to 137 objects. 43 (27 enCore objects) of them are generic. That means they might be used as parent of new objects with very similar features.

A big problem is, that information about this objects is very difficult to gather.

Neither the user nor the programmer manual holds a listing and documentation of the features of this objects. What messages (events) are they listening, what messages are they sending? Which methods let you change their properties? Only with this information one could use effectively the objects.

Conclusion: I ended up with a neat database of servercommands, objects, properties, commands (see picture beneeth) and several information pages on paper and on screen. I could easily search hierarchically through objects and had commands grouped and easily accessible. But still I had no idea on how to work in the way of object oriented programming (effectively using existing objects) with server and database.

Screen-shot above: Only part of the verbs (like the verb at-item(,) are explained. Explanaitions do not show any programming culture. This explanaition pretends that the verb would return a string, in fact it returns an array of strings. Also any experienced programmer would use a third argument for the display format instead of suggesting to hack the code. Due to the idea of object oriented programming one should use general objects "Players Senses" to define output handling. Then all this problems of listing rooms, players, exits, descriptions, dumps, personal messages could be handeld consistently. For instance one could map personal messages to a table, giving each speaker a colomn for his output. Or allowing listings to display as fixed wide, or deliminated by tabs, commas or semicolon.

It even took me hours to get a faint idea of the functioning of the Generic Database. Still I am not certain how to use it effectively, because it follows a hierarchical subrecord approach. I would prefer to implement a more relational approach. That would allow easier datatransfer to external databases.

The persons who worked on the Core-Database do not seem to have any programming culture. They do not use a naming scheme for the variables, verbs and properties. They do not use talking variables like iLineNr. They just use i instead, sometimes writing it in capitals so you have to figure out whether I is a new variable l or the existing variable i. They do not comment their code and objects.

Programming missing verbs

I used my server-code-database in 4D to gather the commands for existing code needed. Then I copied them to BBEdit for programming the code. BBEdit allows drag and drop copying, powerful search and replace and goto line number. After the parser told me a error in the code and I could not figure out what it caused, I realised that I needed some way of checking the code line by line (debugging).

The ;-Code at the begin of a input-line lets you do this in the MOO. I automated entering line of code with this leading semicolon (;). Only, all the local variables are not working with this method. So it is better to stock all variables as properties in a object. I used a child of the generic object (Generic Database Table) that I was trying to program to hold the properties. That worked. Now I think it would be best to create a dedicated object to hold the local variables. So one can replace the properties by one «search and replace» of the entire verb.

All in all, programming MOO-Objects is about five times more time consuming than using a professional developing tool.

I also tried to do the programming in MacMoose. There is a good object browser and one can drag and drop code from and to text-editors. Only MacMoose changes randomly the objects information on the verb.

I could not figure out how to add some functionality to existing verbs. Just copying the entire code of a verb and make the changes there seems to me not the rigth way. On the other hand, using the pass command, I run into problems that I could not understand.

What I was missing is a good written manual. But even then assistant by experienced MOO-Programmers would be needed to do any serious MOO-Programming.

Using enCores predifend objects

The predefined objects of the enCore-Database seem to be quite functional. I put up a Recording system and it worked. Only setting up anything is very time consuming. One should always record such procedures and save them in a text-editor for later processing. I imagine with a lot of such session batches one can manage a MOO. But it will take time to get experienced.

Setting up the library

Well, I did not get far. There is the Rechenzentrum where I put all administrative stuff. There is a conference room and a help desk (room) with a Robot (Assistant) and a recording system (Mirror). But the Assistant is not programmed much. I really did not have enough time to figure out how to mail the recordings of the help desk by mail to me when persons are leaving the help desk. One would not think, that such a easy task is so difficult to achieve even when all needed verbs are there ready to use. But how can I find them quickly?

I tried to change plans and use a container as a book shelf and things as books instead of data-base objects. But I got things working only randomly. Well I was not very motivated. Knowing that the result would be not sufficent anyway there is not much motivation to get over nasty problems. Problems one looses houres just to get a very small thing working.

Conclusion

Guess it would take some months to do the job of finishing the library. Plus I would need some assistance by experienced MOO-programmers.