"Fulfillment" API

Key parts of LilyPad's design is it's ability to act like a cluster, seamlessly linking multiple servers together through a distributed network. With this in mind, key aspects of the server, such as the Connect server and Proxy are expected to behave in a distributed manner, not allowing us to have plugins on them which change their behavior.

Due to the above, plugins like the following are currently impossible without editing LilyPad's internal code:

• Proxy which randomizes or edits the MOTD at runtime.
• The ability to intercept player's connections (for example kick before a server connection is initiated) proxy-level.
• Re-route a player's connection to a different server for a load balancing effect without the creation of multiple proxies.

It is our goal to fill these gaps without breaking our distributed nature.

Events are currently response-less within the Connect API, not allowing an event to be called and a result to be given as is in the Bukkit API (for example). We would like to keep this behavior, and we do not believe we should spend extra overhead on events that needn't have a result.

We will with this said implement a "Fulfillment" API where one server requests (with the Connect API) that an action is fulfilled, and a response is expected. An example:

We would like to customize our status messages so they show the player's username (in the MOTD) based on a cached representation within our database. For this, we register a hook on the Connect API for the action "status".

Now, whenever the proxy requests that the hook "status" be fulfilled, we receive an object along with information about the user (his IP address for example), and we modify the output. The Connect API will then send your response to the Connect server, which will relay it to the Proxy (who requested the fulfillment) and then will be displayed to the client.
​

Issues with this approach:

1. Latency is an issue. If all of the machines on LilyPad's network are running on the same network (like they should) however, we are relieved of this.
2. We need a dynamic way to encapsulate the data we're receiving so it is object oriented. For example, a status request would be a "StatusFulfillment." I was thinking of using GSON to accomplish this, and then pulling the class we convert to from the function with the @ConnectFulfiller annotation.
3. If nothing is listening for the hook (regarding the Proxy's status), the Connect Server would still be contacted regarding fulfilling the request, even though there is no work to be done. It is best to make a cache to relieve this issue.
   
4. Fulfillment is a terrible word for this. If anyone could find a better word they will receive a boat load of praise.

Please post your opinions. Thank you.

Code examples as follows:

The model of the class which is to be fulfilled. This class (as it's pretty common) will likely be directly implemented in the core, but others will be able to make their own fulfillments if they wish

Code (java):

public class StatusFulfillment extends Fulfillment { // should we extend anything? is there a need.
   private String motd; // for example
   public void setMotd(String motd) {
      this.motd = motd;
   }
   public String getMotd() {
      return this.motd;
    }
}
 

The server which responds to fulfillment:

Code (java):

public class Fulfiller {
   public Fulfiller(Connect connect) {
      connect.registerFulfiller(this);
   }
   @ConnectFulfiller
   public void fulfillStatus(StatusFulfillment status) {
       status.setMotd("other");
    }
}
 

The server which requests fulfillment:

Code (java):

Connect connect = ...;
String defaultMotd = "blah";
StatusFulfillment status = new StatusFulfillment(defaultMotd);
status = connect.fulfill(status).await();
System.out.println(status.getMotd()); // "other"
 

And to clarify, the only events available to Bukkit servers is the Message event.

It is part of Client-Connect-API, and will only be handled by new releases of GoLilyPad.

JLilyPad is obsolete. You should not be using it.

I'm not particularly sure what you mean by that? All JLilyPad resources work 100% with GoLilyPad.

Maybe a variant, but that's a much better way to look at it.