sapidlib-dev team mailing list archive

["Cody A.W. Somerville" <cody.somerville@xxxxxxxxx>]

Hello Folks,

 I've been investigating Pike over the last few days and I've came to the
conclusion that although its entirely possible to write a mud in Pike and
would be lots of fun, there simply isn't the security features needed to
allow folks to execute random code like you can in an lpmud[1]. Personally,
I think this is probably one of the things that make lpmuds so fun and so
I've decided to abandon my ambitions for writing a mud in Pike. This is a
huge relieve for me as I've very much wanted to be active in developing the
mudlib we have now but have held back in the fear that I might be investing
efforts in the wrong direction. With this no longer being the case, I'm
hoping to swing back into things and help breath life back into the project.
As I'm sure you're aware, I'm also busier than ever with work. I know
everyone else is busy too. However, I know I can devote a bit of time to
this project again and I hope you can too.

Some initial thoughts and questions:

1. I don't think Launchpad is completely working for us. Although it has a
number of very useful features, there seems to be too much of a learning
curve or maybe more correctly the learning curve is too great for people to
care to want to overcome it (understandable since the launchpad UI has
become a bit of a sore point). Neither do I think the dokuwiki at
http://lpuni.org is working so great for us - people aren't contributing
there and the disconnect between our issue tracker and our wiki is a bit
annoying. I'd like to propose that we switch to something else - something
that integrates everything into one place. Initial scan of the web shows
that Redmin (http://redmine.org) might just be the thing. I know this will
be the third time we've moved around like this so please bare with me and
feel free to throw that as an excuse for not doing anything in this regard.

 Reasons to use Redmine:

* Everything for our project will be in one place - wiki, news, code, bug
reports, etc.
* Integration between components - for example, we can close tickets via our
commit message, link to bugs or revisions in the wiki easily, etc.
* More flexible issue tracker, custom workflows, and custom fields
* Roadmap
* Easier to see overview of all activity in project
* Supports simple forum system which we can enable if we'd like
* Plugins

I'll set a demo up and e-mail people the details.

2. Besides our website and issue tracker, I think our documentation and
process for getting involved or starting to work on something new sucks. I
volunteer to correct this by writing some new documentation and stripping
out the unnecessary shit in existing.

3. Branching, making changes you don't want to commit but need to to start
the mud, starting up the mud, reverting t changes you don't want committed,
committing,  and then remaking those changes you don't want to commit and
starting the cycle again is very tedious and probably is discouraging. I'd
like to fix this by making some changes to the mudlib and how we have the
bzr branch setup. More details on this later.

4. We need to get back in touch with our vision, our purpose. To do this, I
feel we need a presiding goal that gives purpose to the changes we make and
the features we work on. Naturally, we all itch our own scratches and will
continue to do so but what do we say when people ask "What is Sapidlib all
about"? Currently, the answer to that is this huge mouthful:

"Sapidlib (formerly LPUniMudlib) is a small yet powerful mudlib aimed at
creating a solid, versatile, scalable mudlib solution for a variety of
text-based projects including muds (a game genre, text-based MMORPG) that
incorporates revolutionary and innovative features. Sapidlib is modular in
design allowing developers to piece together pre-built modules and easily
create their own. Sapidlib believes in striving for usability, stability,
and dependability and applies these values not only via coding standards but
always in project policies, practices, and procedures. Sapidlib is developed
by the LPuniversity community."

Theres a few good ideas there but its mostly a bunch of power talk:

- small, revolutionary,  versatile, powerful, solid, innovative, scalable
- dependability, usability, stability

If we remove all the cruft, we get this:

"Sapidlib is a mudlib aimed at creating a mudlib solution for a variety of
text-based projects including muds (a game genre, text-based MMORPG).
Sapidlib is modular in design allowing developers to piece together
pre-built modules and easily create their own."

Although we want Sapidlib to be all those buzwords and have all those
positive characteristics, these two sentences really define what Sapidlib
has been all about.

 1. Sapidlib is a mudlib good for all sorts of text-based projects
 2. Sapidlib is modular in design.-
 3. Sapidlib has some concept of "modules"
 4. Sapidlib makes it easy for these modules to be pieced together to create
something bigger.
 5. Sapidlib makes it easy for developers to create their own modules.

As most of you know, I've wanted to create a package management system that
allows us to package different components of the mud into packages (or
"modules") allowing for end users to easily pick and choose what components
they want. Instead of the mudlib coming with a certain type of combat by
default, we can code up a number of different styles and put each one into
their own package. See where I'm going with this? It also forces good
programming principles and would allow for updates to be shipped for
modules. I think this is what'll make our mudlib the next killer mudlib and
spawn a new age for the LPC community where code sharing is both easy and
possible.

What else do I envision for Sapidlib? I want strong integration between
components in the mudlib, cool in-mud tools, menu driven interfaces, project
management facilities, mud management faciltiies (what would make the life
of a mud admin easier?), test suites, and other stuff thats just plain
*cool*.

5. Lasty, I have a few questions for everyone:

 1. What prevents you from contributing regularly to Sapidlib?
 2. Whats motivated you to contribute to Sapidlib in the past?
 3. What can be done to make your life as a sapidlib developer easier?
 4. What sort of things do you want to work on?
 5. How have you been?

Cheers,

--
Cody A.W. Somerville
Software Systems Release Engineer
Foundations Team
Custom Engineering Solutions Group
Canonical OEM Services
Phone: +1-781-850-2087
Cell: +1-506-471-8402
Email: cody.somerville@xxxxxxxxxxxxx