It's Japanese. It means peach blossom. It's the name of tea shop I used to live
near and was obsessed with. The whole project has a tea theme. It's
written in Java, you see. Java is called "Java" because programmers are
archetypally obsessed with coffee. I, however, am obsessed with tea. I do
not like coffee. It's bitter.

Here are some links to the tea shop:
http://momoko.citysearch.com
http://www.momoko-gifts.com

If you are in Austin, TX, go there and order the Taro Root Tea with pearls.

What's standards does Momoko use?

Web stuff is handled by the Servlet framework. Remote file access is
handled by WebDAV. Config files are in .properties format. Distributed
object communication is done over Twisted PB.

What is Straw?

Straw is my RPC protocol and implementation. It runs on top of other RPC
implementations. It was originally written to run on top of RMI, making RMI
stubless and dynamic. The current straw implementation in use runs on
top of Twisted PB. This makes for completely transparent, fast remote
object calls. Straw does not contain any serialization or transport code.
It simply adds a layer of abstraction on top of normal RPC so that you have
remote objects that look just like local objects.

Why use Straw instead of RMI, XML-RPC, or CORBA?

Straw has two major benefits: it's stubless, and it interacts with normal
objects. If you want to use RMI or CORBA, you have to have your classes
implement certain interfaces and you have to run a command line utility to
generate stub classes and you have to distribute your stub classes. With
Straw you just take a class you've already written or have in a library
and call a method to register it. Or if the object is referenced from a
registered object then you don't do anything at all. You only need to
register "root" objects which serve as starting points for a remote
process.

XML-RPC works similarly, but it doesn't support returning references to
remote objects. With XML-RPC your functions can return primitive types
and a few Java classes, but not arbitrary user-defined objects.

Note that I did not write my own transport or serialization mechanisms.
Straw is a high level mechanism that runs on top of existing systems
such as RMI, CORBA, and XML-RPC. Straw does not replace them, but
enhances them in necessary ways.

What languages are supported?

Currently only Java is supported. Python and Scheme have been supported at
various times.

I am starting the process of reintegrating scripting language support,
starting with Scheme and probably Python next. You can look for this
sometime in the 0.4.x series of releases.

Can Momoko support language X?

Any language can be supported which can either 1) be translated into Java
or 2) be interpreted by a program written in Java. I know that Java,
Python, Scheme, TCL, and Perl are all possible. Actually supported
languages will probably by Python and Scheme since I like these. Anyone
is free to write modules to support other languages and I'll include
them in the release if the libraries aren't too big. Also, if you request a
language I'll probably add support for it.

What object/inheritance model does Momoko use?

Java uses the class model, therefore so does Momoko. It used to have
a prototype model. However, I decided that there were more important
areas of work to do other than making a layer of top of Java which
includes such niceties as multiple inheritance, prototype objects,
operator overloading, etc.. All of these things are wonderful, and should
be provided to Java programmers in the form of preprocessing tools which
produce Java source or bytecode. However, I decided that I didn't want
this to be my area. Instead, you can write such tools and make them
available as Ant tasks. Integrate them into your build process. All of this
sort of code has been taken out of Momoko.

Do you want a job?

Yes, that would be nice. I'm currently looking for employment hopefully
doing distributed computing or peer-to-peer networks. I also do general Java
programming, CMS, enterprise database stuff, the usual. I have a resume at
http://blanu.net/resume.rtf. I am currently looking for employment and would
appreciate any leads. This question was actually asked and so I put it in the
FAQ.

What is included in the minimal db built when Momoko runs with no db?

Only those things which are necessary to booting are included: the root
object, an Admin object, and a class loader. The included test.script
file creates a few more interesting objects when the server is started.
Look in workspace/test.script to see what it is creating.

Does Momoko have any builtin code for basic mud objects such as rooms and
players?

Yes, it is in the momoko.extra package and subpackages. There is code
for navigation between rooms, describing rooms, and basic communication
such as saying, whispering, and emoting. I'd be interested in
collaborating with anyone who would like to build a MUD-like environment
on top of Momoko. I will personally be concentrating on the more general
aspects of Momoko as an application programming and deployment
environment. I am, however, working on a 3D graphical virtual environment
for playing online abstract strategy games. So enquiries regarding that would
also be favorable.

Can the environment be developed online? In other words, can I make
drastic changes to the internal database without restarting the server?

Yes. The source code is available via WebDAV. You can access all of the
source files remotely and modify them. Then, from within the Momoko
command shell, you can invoke the "ant" command to rebuild the system.
New instances of changed classes will instantiate the new version of
the code. The classes in the momoko-system.jar file (generated by "ant
libs") cannot be reloaded without restarting the server, for reasons
of quirkiness in the Java class loading mechanism.

The WebDAV server is bound by default to http://localhost:9090/. I recommend
using SkunkDAV (skunkdav.sourceforge.net) to access it, as it's known to
work well.

Is it difficult to distribute a database which will work with Momoko?

Not at all. Momoko doesn't rely on a specific database format. So you can
write a database driver for any database you like. There is a standard,
default database format which uses the JSX library to save object
trees as XML files. It's platform independent and pure Java, so you can
distribute in that format.

Will incompatabilities exist between server versions?

No, as of Momoko 0.4.1, the framework is considered to be mature. There should
not be any changes noticable to users for a long time.

How stable is Momoko?

Load testing has show it to be very stable. Even memory leaks in application
built on top of Momoko has been unable to crash the underlying server.

How fast is Momoko?

It is quite fast. Modern Just-In-Time compiler technology means that on
most platforms it runs as native code. The distributed object mechanism is
very compact, easily outrunning RMI, CORBA, and XML-RPC. The default
persistence mechanism is somewhat slow, as it produces and parses XML files.
However, you could easily replace it with a different persistence mechanism
if you can find a fast enough somewhere. My research into Java
persistence mechanisms has shown that they are pretty much all bad at this
time.

Won't interpreting python from inside Java be really slow?

Yes, it is theoretically fairly slow. If you had a large amount of python code
being interpreted simultaneously then it might not be fast enough. However,
modern computers are incredibly fast as compared to the amount of computing
that most applications actually consume. In short, if you're going to be
hosting a truly massive object database with lots of simultaneously
execution, don't use the python scripting.

Has this ever been load-tested?

Yes, it has been load tested both in short-term high-load situation and
in long-term constant-load situations. It stood up very well. I would be
happy to produce some more formal benchmarks if there were something to
benchmark against.

Is there anyone anywhere using this for anything currently?

There are a number of projects based on Momoko. The two most developed are an
online forum consistening of an integrated web-based forum and mailing lists
and a remote desktop environment that allows you to carry your desktop around
with you wherever you go. Momoko has also been used to write IRC bots.
There is currently a distributed multi-user game engine being written, but
it is not available yet.

Are there any gaps in functionality preventing me from using it currently?

You'll need to write your own internal permission system. Straw takes care
of permissions between servers. However, internally any object can modify
any object unless you take provisions to prevent that. This is not an
issue except for applications in which users get to send code to the server
to be executed. The simplest way to handle this is to only allow users to
execute scripts, and run the scripts inside a sandboxed interpreter.

What can't I log in?

Passwords as case sensitive.

Is Momoko more like MOO or ColdMUD?

ColdMUD. Although the interface is getting to be more MOO-like. I'm an
old-time MOO programmer, but I stole a lot from ColdMUD.