[MUD-Dev] Middleware (was re: Sun's Sim Server andGordon's10Reasons (thefirstone :))

[Matt Chatterley]

From: John Buehler
> Derek Licciardi writes:
>> From: Michael Sellers
>>> Raph wrote:

>>>> To broaden the discussion a little to the general topic of
>>>> server middleware/server codebases: what's the general feeling
>>>> of the list on this issue? My personal take is that middleware
>>>> generally makes too many assumptions that end up constraining
>>>> the eventual game design--plus, you have to rewrite most of it
>>>> anyway or end up with generic stuff. This has seemed to me to
>>>> be true with muds and true with MMOGs.

[snip]

>>   "I think middleware becomes viable when the design space has
>>   been traversed often enough that it's pretty well-known."

> As an advocate of component software development, all of this just
> screams "components" to me.  The "I think" statement is actually
> saying that a separate set of components can be created once the
> problem space is understood well enough.  Where "well enough"
> means that the designers can formalize some kind of standard to
> represent a good solution for that problem space.  In the
> component world, that standard is called a software contract.
> Often embodied as interfaces.

[snip]

> "Go Components"

For what its worth, I'm strongly in favour of component orientated
development. By day I work on a very large web application, where
code reuse is almost a survival trait, and by night, I write my own
PHP pages - and where possible, try to reuse my own code.

Some examples are simple. There are lots of places within my current
project where I want to prompt the user to enter day/month/year for
a date into a form, so I have created a generic DateBox component as
a PHP object, which I can re-use. There are lots of places where I
need to output the results of a SQL Query in an HTML table for
display (possibly using a form as well for information write-back
from the user). Hence my 'InfoGrid' component was born.

While this isn't exactly 'middleware', it's good practice to me, and
also common sense - perhaps it IS necessary to invent the wheel. It
isn't necessary to invent it six times in the concept of the same
program (or even different programs). I don't really like using 3rd
party components/objects within my applications if avoidable - and I
won't for anything relatively small.

However, if you start to talk about the kind of 'components' which
are likely to be considered middleware (3d engine, database server,
web server, email system - I personally group all of these together
to some extent), then you would be giving up a significant portion
of your development time to an engine or mechanism which is required
for your software to function - possibly longer than it would take
to develop the rest of the software itself.

Also, from my point of view, I am a strong web and database
programmer. I am NOT a low level developer, and I wouldn't know
where to start with, for instance, anything I mention above - so I
know I wouldn't be able to do as good a job as a group of experts
who have created their 'middleware' application.

Of course, as this thread is showing, choosing good, proven
middleware is a different matter altogether...

Cheers,

Matt
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev