Members - Reputation: 308
Posted 22 August 2005 - 07:06 PM
Members - Reputation: 742
Posted 22 August 2005 - 07:45 PM
If two plugins are ever dependent on each other, then they are no longer two seperate plugins since it completely violates the concept of code that can be swapped out. Instead, it is a mess and should be given a quick death.
Members - Reputation: 308
Posted 22 August 2005 - 08:22 PM
The general idea is to stick with exposable properties and use messaging system to communicate between plug-ins.
Second idea is to create plug-ins as DLLs (which they are) and use interfaces to provide general functionality for each impl .
So, what you are saying, interest86, is that the second way is a better one. OK. I'll try it. Thanks (rates up both).
Members - Reputation: 874
Posted 22 August 2005 - 08:35 PM
Basicly what it does is to:
For a light variant of this you could probably simply build it upon typeid or dynamic_casts.
Messages are great for when your plugin doesn't need to know (or doesn't care) who it is communicating with but you can easily end up with an overly flexible system that can be very hard to follow (been there done that).
In a past project I implemented a fairly robust messaging system the problem was that when deadlines were looming neither I or anyone else on the team actually fixed design issues we started to simply send a message and hope that someone-else somewhere sometime would see the message and do something sensible. It pretty much implodeded with a gigantic monolithic message handling function that was to say the least hard to comprehend (and it still didn't actually do everything we had clumps of message handling code everywhere).
Anyhow, messages are great, just keep disciplined if you plan on using them.
Members - Reputation: 308
Posted 22 August 2005 - 09:26 PM
I understand the complicated nature of the question, it's really hard for me to explain what I'm after. All I want is to have my engine is to be extendable, and be extendable easily and without much effort. I can achieve that by using interface classes and restricting user to certain functions, but I'm just not sure that this is a proper way. I mean, look at the HL SDK. You can write MODs (and many people did) with it. That's what I'm aiming at. High flexibility + ease of use.
Members - Reputation: 1464
Posted 22 August 2005 - 09:41 PM
This way any process (class) that want to use another class had to know just two things. The header file for the class and its tag in the map. Any class can ask for a pointer to any other class in the kernel and asks the kernel.
You understand what i mean?
Members - Reputation: 289
Posted 22 August 2005 - 09:46 PM
Your first idea is not far from Windows messaging or some kind of transaction service. Depending on what your software is doing, it might be quite possible to create discreet packets of information which can be passed around and intercepted by the modules which are interested in them. You could use something like the Observer design pattern for a registration mechanism. You could also use the Iterator design pattern for a mechanism to iterate through the various modules, interrogating each one to see if it supports something that other modules are interested in. (Hope that makes sense)
Members - Reputation: 340
Posted 23 August 2005 - 12:32 AM
My day job is working on a message passing system for control and simulation of autonomous vehicles. It's built from the ground up with support for distributed plugins and real time programming. Most of the time the system is fantastic - debugging can be a pain though.
Our implementation of plugins provide a very minimal interface (just a run method) and inherit support for basic operations (bootstrap parameters, reads and writes to a real time database) from a base class. Inter plugin message names are supplied configuration files (although we're in the process of upgrading the process to conducted through a scripting interface).
* The minimal module interface makes inter-language operation a breeze. We have three languages which are currently supported (C++, C and ada) and plans to add support for more (python, C# and lua)
* Multi-developer support. Most programmers just have to know how to write a simple single threaded application that follows a minimal set of rules (on data passing and termination) and don't have to get their hands dirty with the ins and outs of plugins and communications.
* Third party software support. Having a minimal interface means that third party implementation details can't leak out of a module (the design tends not to deteriorate as much because you can't 'just add this one little special case').
Problems in the design include:
* Loss of type safety in passed messages.
* Data needs to be serialized before message transmission. This operation is either dangerous (casting and relying upon similar sizes and data layouts on both ends) or expensive (conversion to stings)
* Data runs through a central 'hub' which is then broadcast to subscribers, an operation which in our case is relatively expensive because of synchronization, and is in most cases overkill because most data is only likely to have one subscriber.
* As has been mentioned before, if the names of the messages don't match or get out of sync you don't get any results in the best case and block waiting for data that will never arrive in the worst case.
* All of our plugins run asynchronously - depending on your needs you may need to offer some support for this. I assume this would be an issue in a graphics heavy environment, you certainly don't want a single plugin 'hogging' when you want to be rendering.
* You end up with a plugin for everything.
For our work, we develop a large number of very similar systems and it's really convenient for everything to talk seamlessly together. However, it's worth noting that we only really move around data without much structure (lots and lots of numbers), and doing anything else would be a pain to code and likely to be quite slow.
Personally I think a group of programmers who communicate together would be far more productive with option 2. Option 2 is really just a synonym for design by contract, which makes testing and collabrative development far simpler.
Posted 23 August 2005 - 03:18 AM
I had a message based system with similar intend working. But using it felt a lot less structured. Unless you really design your whole system to be totally message/event based you run into a couple of problems (or maybe that was my designs fault..). I had to introduce a mechanism that allowed to force the server to process all messages in its cue(fifo) until it encountered a STOP message. That way you could synchronously request an interface/value/function, post the stop message and call a special function that processes the fifo until STOP. So that after calling the special function your request had been fulfilled and you could start using the interface.
Anyways..I'd suggest not using messages unless you have a truely asynchronous system that requires a dedicated event based protocol anyways. For the cases where you need that (networking,..) you could create a plugin.
Members - Reputation: 308
Posted 23 August 2005 - 04:16 PM
I would rather stick with interfaces for now and avoid using messages. Thanks to all again for help, it's really appreciated.
Members - Reputation: 384
Posted 24 August 2005 - 02:36 AM
Crossbones+ - Reputation: 1709
Posted 24 August 2005 - 05:58 AM
Using Interfaces with Dlls
Creating a Simple Dynamic-Link Library
Using Run-Time Dynamic Linking
Adding Plug-ins To Your Application
And 3 of my old threads that contain some helpful responses:
Using classes as plugins via dlls
Plugins - .DLL/.LIB question
Plugins 2.0 Updated