Re: [Open-mind-developers] New net API

[Michel P. <mi...@di...>]

On Mon, 2004-03-22 at 03:17, Alban Cousini=C3=A9 wrote:
> >The more I think about it, the more I think any kind of plugin class
> >loading mechanism should not be included in the net library.  The
> >library should, of course, be able to use plugged in classes, but the
> >mechanism for loading plugins from a directory or network or whatever
> >should be done by a separate component.  This separate component could
> >load plugins for the network library and other OM components.
> >
> >This makes the net library simpler and usable to other programs, the
> >programmer (or some plugin loader) just registers factory objects on t=
he
> >net library.
> >
> Agreed. The more I think about it too, the more I think using plugins=20
> doesn't really make sense :
> - As Jan suggests, using reflection would impact performance and make u=
s=20
> lose the performance benefit of using java.nio classes.

The PluginClassLoader I sent in a previous email does not use any
reflection, but beside that point, I'm still very much in favor of
plugins.

> - Using plugins is only usefull if you distribute a program to end user=
s=20
> (such as photoshop users) that don't have a clue of how to compile a=20
> program

I agree.

> , so they can plug third party programs that could be developped=20
> monthes after the release of the main program. But with OpenMind we are=
=20
> targeting a public of game developers, not end users, so these people=20
> have the technical qualification to add the usage of new classes, and=20
> with open source we are going to release real time upgrades of the=20
> OpenMind plateform, so there is no real need  for plugins : just get th=
e=20
> updated SDK, compile the jar libraries and you're done.

I don't see plugins as a way for us to communicate new components with
developers, but for developers to communicate new components to their
end users. Plugins provide a tool to the developers that allows them to
easily update their end-user's installations.

With plugins, developers can ship small improvements to users in smaller
chunks rather than an entire redistribution.  The end user (or the game
itself) only needs to download and plop the class files into a
pre-configured directory and rescan it, the PluginClassLoader will
handle everything else.  No recompiling necessary.

When someone develops a new game and ships it, they can still provide
incremental improvement in some areas, like better network delivery
algorthms, by delivering new plugins.

Note there's no reflection involved, no performance hit, only a one time
startup cost when the plugin directories are scanned.  If the
directories don't exist, there's no performance cost at all.

Now there is probably a big security downside to plugins if users are
allowed to download and execute code from just about anyone instead of
just one trusted source, the game developer.  ClassLoaders do offer
integration with the Java security system, but it is up to the developer
to adhere to it.  With rigourous security design the ability to transmit
both code and graphics between peers could be cool.  Think Java Wars.=20
My class file kicked your class file's ass!

-Michel