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:
If you are in
Austin, TX, go there and order the Taro Root Tea with
standards does Momoko use?
Web stuff is
handled by the Servlet framework. Remote file access
handled by WebDAV. Config files are in .properties
object communication is done over Twisted PB.
Straw is my RPC
protocol and implementation. It runs on top of other
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,
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.
Straw instead of RMI, XML-RPC, or CORBA?
Straw has two
major benefits: it's stubless, and it interacts with
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
similarly, but it doesn't support returning references
remote objects. With XML-RPC your functions can return
and a few Java classes, but not arbitrary user-defined
Note that I did
not write my own transport or serialization mechanisms.
Straw is a high level mechanism that runs on top of
such as RMI, CORBA, and XML-RPC. Straw does not replace
enhances them in necessary ways.
languages are supported?
Java is supported. Python and Scheme have been supported
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.
support language X?
can be supported which can either 1) be translated
or 2) be interpreted by a program written in Java.
I know that Java,
Python, Scheme, TCL, and Perl are all possible. Actually
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.
object/inheritance model does Momoko use?
Java uses the
class model, therefore so does Momoko. It used to
a prototype model. However, I decided that there were
areas of work to do other than making a layer of top
of Java which
includes such niceties as multiple inheritance, prototype
operator overloading, etc.. All of these things are
wonderful, and should
be provided to Java programmers in the form of preprocessing
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.
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
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
file creates a few more interesting objects when the
server is started.
Look in workspace/test.script to see what it is creating.
Momoko have any builtin code for basic mud objects
such as rooms and
Yes, it is in
the momoko.extra package and subpackages. There is
for navigation between rooms, describing rooms, and
such as saying, whispering, and emoting. I'd be interested
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
environment. I am, however, working on a 3D graphical
for playing online abstract strategy games. So enquiries
regarding that would
also be favorable.
environment be developed online? In other words, can
drastic changes to the internal database without restarting
Yes. The source
code is available via WebDAV. You can access all of
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
difficult to distribute a database which will work
Not at all. Momoko
doesn't rely on a specific database format. So you
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.
incompatabilities exist between server versions?
No, as of Momoko
0.4.1, the framework is considered to be mature. There
not be any changes noticable to users for a long time.
has show it to be very stable. Even memory leaks in
built on top of Momoko has been unable to crash the
It is quite fast.
Modern Just-In-Time compiler technology means that
most platforms it runs as native code. The distributed
object mechanism is
very compact, easily outrunning RMI, CORBA, and XML-RPC.
persistence mechanism is somewhat slow, as it produces
and parses XML files.
However, you could easily replace it with a different
if you can find a fast enough somewhere. My research
persistence mechanisms has shown that they are pretty
much all bad at this
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
execution, don't use the python scripting.
ever been load-tested?
Yes, it has been
load tested both in short-term high-load situation
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
anyone anywhere using this for anything currently?
There are a number
of projects based on Momoko. The two most developed
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.
any gaps in functionality preventing me from using
You'll need to
write your own internal permission system. Straw takes
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
can't I log in?
more like MOO or ColdMUD?
the interface is getting to be more MOO-like. I'm
old-time MOO programmer, but I stole a lot from ColdMUD.