Plugable, distributed framework

What hole are you trying to fill?

Well, that's a simple one… The framework I'm working on aims to make the coding of a distributed server envorinment as simple as possible. All you need to do is created Plugins and write an XML config file.



Are you looking for additional contributors?

The basics are all there, what I really need is someone with network expertise. The network layer I currently use seems to create a lot of lag, which needs to be fixed.



Is it done or are you committed to further development?

The current version has all the basics already. The plugable architecture works, the messaging system works, the server-to-server communication works and I recently added a central Plugin registry.

The next thing that needs to be done is code clean up and streamlining of the whole thing to increase performance. This is especially important with the network layer which handles the server-to-server communication.



Are there any related threads or articles of interest?

http://sourceforge.net/projects/pffj/ This is the sourceforge page of the project. The wiki is reasonable up to date, it just misses the registry. The same goes for the file download. That one doesn't have the registry either. The registry is only availlable in the SVN.



When you download the code from the SVN, I uploaded the entire Eclipse project, with all the needed libraries etc. supplied with the project. So you should be able to run it without problems. If you do run into problems, let me know and I'll see if I can fix them.

In the project there are two source folders. src, which contains the framework code and test which contains the test cases. When running the registry test case, the runner for the actual registry is located in the src folder.

Oh, and the stand alone testcase as well as the distributed reader and the registry reader tescase need one parameter, the file to read.





I seriously hope you guys will give my framework a spin, since it is beginning to look like it could really make distributing computing easy as pie.

With the Open Game Finder this framework has gotten a use case I can wrap my head around, so I figured this would be the right time to inquire a little further about PFFJ itself.



The part I'm still in the dark with is how exactly this framework would be applied to the libraries it ties together. What would be a good idea to plug in, and what not? Take jME and Nifty for instance. Do you think your framework would to just as good a job plugging Nifty into jME?



And what about your own implementation for OGF. Is jME+Nifty considered one, or do they come together in separate parts as far as your plugin framework is concerned?



I might not be asking the right questions just yet, but I'll get there :wink:



Another curiosity of mine is whether or not any changes would be required to the 'plugins' in question (jME, Nifty, SpiderMonkey etc.) in order to work optimally with PFFJ.



I guess my biggest gripe is, in what context do you implement PFFJ instead of integrating necessary libraries into jME directly, specific to your own project?

erlend_sh said:

And what about your own implementation for OGF. Is jME+Nifty considered one, or do they come together in separate parts as far as your plugin framework is concerned?

At the moment I have JME setup as the main applicationwhich makes use of PFfJ. Nifty in turn is implemented as a Plugin in PFfJ. This works great, and it allows people to switch Nifty for their GUI of choice without any problems because it is comepletely self contained. It does pose some problems which relate to your following question.

erlend_sh said:

Another curiosity of mine is whether or not any changes would be required to the 'plugins' in question (jME, Nifty, SpiderMonkey etc.) in order to work optimally with PFFJ.

The biggest problem so far for me was initialising Nifty in a plugin. The problem was the the NiftyJmeDisplay constructor needs variables which are contained within the JME Application. The whole idea about running in a Plugin is to decouple the NiftyPlugin from the main JME application. As a reasul, the NiftyPlugin has no access to the needed variables. For now I solved this by setting up a GuiContainer class which contains these variables as statics. That way, the main JME application can set the variables after which the NiftyPlugin can access them while I still maintain the seperation between the two.

erlend_sh said:

I guess my biggest gripe is, in what context do you implement PFFJ instead of integrating necessary libraries into jME directly, specific to your own project?

Usually it should work just as well to just link in the libraries. But since OGF is meant as a structure that other people can uise, I decided early on that each part should be easily replacable. Also I want people to be able to extend it where they wanted to. All this speaks for a pluggable framework, which is where PFfJ comes in.

I hope this answers a lot of your questions, if you have more please send them my way. I am on the verge of starting on the OGF server (if I can find the time over the weekend...). After that, PFfJ should become a bit more clear.
ractoc said:
I hope this answers a lot of your questions, if you have more please send them my way.
I think I've had an ever so little revelation :-o

I made a drawing of my newfound understanding of PFFJ. So right now my understanding of PFFJ in a nutshell is: For when multiple systems need to plug in (integrate) to the same asset (another system).

So for example, while jME and Nifty will go together just fine in a custom integration if that's all you need. On the other hand, if you're combining jME, Open Game Framework (with OGF also using Nifty, and not as an internal of jME) and Nifty, then PFFJ will make your use of Nifty (or any alternative GUI) much more manageable, since you won't be dealing with both a jME+Nifty and OGF+Nifty integration, but rather just making Nifty work as a plugin.

Am I on to something here?

(I noticed you can make jMonkeyEngine a parent of sorts in the plugin hierarchy, but I don't think that's important to this mockup)

That sounds about right yes. Like I said, I currently have JME written straight into my main startup application, but the plan is to move that to a plugin as well, so all the main startup does is stsartup the PFfJ controller and then send a message to start the game to the JME Plugin (or whatever your engine is…)

After that, everything will run through PFfJ, which means you can customize just about anything, the GUI (Nifty, GBUI, …) The Network layer (SpiderMonkey, JGN, …) but even the complete GFX engine becomes easily replaceable.