ServerService

[Defman]

This will expose a ServerService which would be implemented by a plugin that would create a bridge between a proxy and the ServerService, the proxy might be BungeeCord.

public interface ServerService {
  void transfer(Player player, Location<Server> location) throws ServerException;

  Collection<? extends Server> broadcast(Text message);

  Collection<? extends Server> getServers();
}

public interface Server {
  void broadcast(Text message) throws ServerException;

  void transfer(Player player, Location<Server> location) throws ServerException;   
}

The Server would also implement some sort of message broker.

I'm also proposing changes to Extent to allow Location to work across servers.

It might also be useful to implement methods for configurations, onlinePlayers, etc.

[ryantheleach]

I'd love to see this in the base API, but I worry about how much extra work it is in order to get deep enough integration.

The ServerService would need to provide a little more information in order to get Locations to work as you want, and this could potentially have some ramifications depending on how deep integration is expected to be.

At minimum, I see that teleporting (cross world teleporting to be exact) would need to be made ServerService aware, not to mention the respawn systems.

The problem is where to draw the line, do we start making methods available to list all online players? a cache of them? do we allow command elements to complete based on the online player cache?

There is a LOT of depth that could be added by nice integration, but at the same time, each of these adds additional complexity.

@ojbr I suspect you have some opinions on this, if you see this notification.

[Defman]

Currently the Location<E ? extends Extent> just contains a Vector3d that may exist in a extent. What if Location was changed to the Location<E ? extends ServerExtent>. Where extent stays as it is but ServerExtent only contains a reference the ServerUUID and ExtentUUID and make some. The above is just a stream of thoughts and inputs are more than welcome.

[dualspiral]

This is personal opinion and does not hold the views of Sponge in general.

API hat: An API that doesn't have an implementation in Sponge should only be reserved for popular operations where it makes sense to unify them and maintain the standard, such as permissions and economy, as many plugins make use of these. This is an API only few plugins and server owners would really make use of, I think. If the Region API isn't making the cut (not saying it isn't, but it has been stalled for a long time), this certainly shouldn't.

Implementation hat: Sponge is server software. It is not server network software. If you start making methods cross-server aware, then plugins are going to break. Plugins are rightfully written to assume the local worlds. Sure, you could some fancy work to have RemoteWorlds as some Extent, but then when an event happens remotely, does an event get fired locally? What about if you interact with the remote world? Where does the event go? What about the PhaseTracker? Do we suddenly get a lot of lag because we now have to do network operations on the main thread every time someone tries to respawn?

In my personal opinion, Sponge does not, and should not, have a reach outside of its own server by itself, nor should it consider that. The intricacies of inter-server communication that suits everyone cannot be summed up by an API like this. Some plugins won't want to do config syncing. Some plugins might just want to broadcast to all servers from one server.

If you want to allow plugins broadcast to all servers, create a custom message channel that can do that and provide that. If you want to switch a player's location on respawn to another server, a plugin should do that using event cancellation and message sending. With regards to Extent, if you want a remote server extent just extend this interface. It's an interface that you can implement directly if you want, and you can then use that in locations.

A plugin library that handles the various events and such should do this. Sponge should not provide the notion of it.

Finally: A lot of us are stretched as it is. To provide this API support in our implementation is going to cause a lot of hurt, break assumptions, introduce a wealth of bugs and delay other things that people have been waiting for a long time.

I don't think this is something that Sponge should support as an API and should be left to the plugins who have a much deeper understanding of the problem they are trying to solve, and not have us force a way to solve it upon them.

[Defman]

@dualspiral I agree with you 90% of the way. A Service should not be implemented in any way that it would break plugins. The entire point of Services is that they are optional and may or may not be implemented by custom plugins. And therefor the idea of implementing it with Location should be dropped. But I still think we need a ServerService; I believe theres a need for this i some way. The idea of splitter Players across multiple instances and worlds to be able to sustain a high player count and splitting load across multiple cores is essential.

As a final note all servers should be responsible for it self and its events, no remote server would ever be responsible for such events without explicit implementation on both servers.

[ryantheleach]

Yes, I was thinking slightly ambitiously, as for cross-server events, no I wouldn't ever think of doing that with a Mojang based server.

Remote worlds are similarly too difficult.

However cross world/server teleporting I think, is one of (very few) areas I feel I would be ok in having support.

But designing API that can handle that seems tricky.

Common things that people need out of bungee.

Cross-world player and entity management.

Kick, Ban, Teleport, Tab completions, Messaging, Locating, singular and inheritable configuration, server spin up/down.

Most of the rest can be supported reasonably well by dedicated plugins.

Areas I think having an API in Sponge could improve over hooking proxy API directly.

Transfer of entities/teleport. e.g. serialize the entities data, filter the entities data, and literally potentially let them take their inventory/horses with them. (would need some form of proxy support, but @Aikar has done it before)

Plugins having better awareness of 'online' users. (Not players)

I can't think of many reasons when a cross server broadcast is appropriate, But I've not played enough to know.

[dualspiral]

I know what the point of services are. The problem I have is that by having this service, you're putting the onus on other plugin developers to use this service if it exists - and it's a service that won't normally be populated. You change the entire assumption of the plugin ecosystem by saying "hey, you may need to consider a linked server now, but not always". That just feels wrong to me.

But I still think we need a ServerService; I believe theres a need for this i some way. The idea of splitter Players across multiple instances and worlds to be able to sustain a high player count and splitting load across multiple cores is essential.

Splitting up players across multiple instances is not a need of the many. It is a logistical nightmare to get something like this right. You also don't say what exactly you would want from a service, only that you want one and give suggested methods.

If a plugin wants to send messages to other servers, we have events for picking up on that, we have MessageChannels that can be used to that effect. If you want to get all players, well, that's very much environment specific and we don't control the BungeeCord system and it's deriratives. You might not be using Bungee, you might be using Lillypad. You might have a custom solution. Sure, a plugin would implement the service, but every server is different in how they operate and you cannot expect one plugin to implement everything in the service.

We should not be expecting plugins to support this by providing this service. Plugin developers should be receptive to providing APIs for making this possible with their plugins. There are things you can do without this support, as I said, message channels make this somewhat easier by providing a channel that allows the message to be sent off server.

---

I have to go back to the point that Sponge is game server management software. It is designed to enhance Minecraft, not turn it into an instancing system, or change the underlying assumptions of the game engine where it is entirely isolated. Getting things to work with Bungee is enough of a hack. This ultimately would require major changes to the underlying implementation to get working reliably, and to make it work well with plugins.

This problem isn't solved by the simple addition of a service. This is not a simple problem to solve. This is solved by a custom implementation that is instance aware and can sync up reliably, and I do not think that it's ultimately in our best interests to do.

[ghost]

Have to agree with @dualspiral here. Server clustering with multiple running implementations of SpongeAPI is probably a bad idea for the project. Not a bad idea in general, but the API has never been built with distribution in mind. You're going to end up running multiple instances of the plugins across the network, one copy per node. That's a lot of resources.

[Defman]

When I original wrote this, I few days ago I was not sure what I wanted entirely, witch in result created this unclear issue. Personal I see the pros and cons of a StandardService and I just want a discussion. I'm going to implement something on my own to take care of my needs, but if I have the need someone else out there might also. I'm going to implement my own bridge between what ever proxy I might use so that in the future I might switch it with out too much hassel.

Currently my need is to transfer players between server to an exact location. The implementation should also allow me to handle errors gracefully if and when a server goes offline. Some kind of message broker would also be useful for all sorts of things.

Final note: Any thing to do with proxys and such might just be a bad idea for sponge, it might push sponge into something it was never ment to be. It might just be beter to leave such a thing for a 3d party.

[ryantheleach]

@The-Defman I still think it was a valuable discussion / topic regardless. It's hard to judge what people think without discussing it, so thanks for creating the issue.

I'm planning on leaving this open for about 2 weeks without a reply / consensus, then close if a resolution hasn't been made.