tchize wrote:
And for everyone out there currently using grep - download cscope and use
that
- it is a vastly superior solution (even going to plugins or whatever else,
cscope is a very handy tool - just run 'cscope -R' in the top level
directory.
Am not sure it's a good idea to have de developper dependency on cscope or
grep.
But at some level, you will always have some dependencies on other tools -
compiler, linker, editor, etc. I was mostly pointing out that if people are
currently using grep, there are much better tools available.
True, but that goes more back to my 'poor mans version' of plugins.
At some level, I think a poor mans version with callback registration is
actually more flexible.
You'd have to issue a 'patch' if you want to add third party specific
features
(like a server having it's own crossfire - html stats system). You'd have to
'patch' the code if you want to disable compilation of a problematic piece of
code.
True, but a plugin for object actions would be a pretty critical piece of
code
- you just can't disable the players from applying all items (or not compile
that bit) and have a working system.
Now the counter is that you'd just disable it for the specific bad object
type, but then, if one plugin is covering 30 object types, that still isn't
much
an option.
IMO, compiling/not compiling something isn't an issue - if something is so
broken that it doesn't even compile, it should be fixed ASAP or be removed.
the issue would more likely be disabling them once problems start, which
would
be same regardless of method used, but registered callbacks are probably easier.
One could have a registration function like:
set_type_callback(object_type, event_type, callback())
The advantage of registration of that form (instead of true event plugs in
the
object) is that adding new event type callbacks doesn't require any change
to
the objects.
What's the difference with
set_type_callback(object_type, event_type, somePluginMethod()) ?
the fact of adding plugin event to object instead of type, is just a
generalization of what is currently done for existing script and is needed to
keep backward compatibility (not to mention it also allow plugin to have some
methods triggered only on demand).
Well, you can't have a single list of all the set_type_callbacks() unless all
the functions are in the same module.
For example, you can't have any such callbacks in the server code if they
reference functions in plugins that are called later.
Likewise, for the plugin itself, it will only know about the functions in the
plugin itself.
This isn't directly a problem except that these callbacks would be spread
across several plugins, which makes finding the actual details more difficult
(have to do a grep to see which file is registering that callback).
For most plugins, that probably isn't a problem - if one were to think of the
random map code, it really only needs to register one callback, so big deal.
OTOH, the random map code is already pretty well modularized, so I don't see
much point to convert that to plugin logic.
Moreover before thinking of the specific ways to modularize things, questions
to be answered must be
- Do we want a modularized system?
- If yes, who would lead this process, how will he lead this, and who would
team with him.
I think the term plugin vs module probably needs to be clarified, as well as
clarification what approach we are really taking.
To me, module is like the .a files currently used (random maps, socket, etc)
-
code is logically grouped in one place, but linked in at compile time.
plugin is code that isn't loaded until run time by explicit calls to load
shared libraries. In this case, the server (or other code) doesn't know about
anything in the plugin until the plugin is loaded.
Now a separate question may be which method should be used - modules are
certainly simpler to do, but harder to control usage of that code.
I guess for the object code handling, I'm more inclined to do a module type
approach - that code is already compiled in, and I don't see much in the way of
compelling advantage to making it an actual plugin - the code can be made a lot
easier to maintain and find stuff without making it an actual plugin.
That said, I can certainly see the need for plugins. It just becomes harder
to figure out what approach works best for what.
That is one consideration. Another is whether the any of the plugin logic
itself would prevent proper re-entry (eg, static values in wrapper
functions, in
case of python plugin, is there anything to prevent two python scripts from
running properly at the same time, etc).
That's tipically a problem associated with multithreading. I don't think it's
a good idea to mix the ideas of multithreaded core and the ideas of
modularized system. One big change at a time
