Hi, I am requesting an enhancement of the SGS API.
I am designing the new version of Jnag for SGS, and I found an obvious incoherence in the API:
The classes “com.sun.sgs.client.ClientChannel” and “com.sun.sgs.app.Channel” are both a channel that allow to send some messages to another network entity, but they share absolutly no type at all ???, making the API totally asymetric.
This become a problem for all the user-defined classes that want to work with both the client and the server (like my API, which is perfectly symetric and doesn’t - and doesn’t want to - differenciate the client and the server in its usage). :-\
It would be nice to have a common super interface to those 2 interfaces that contains the 3 methods to send the messages and the function to get the name of the channel.
Also, if I was the designer of the API, I would rename com.sun.sgs.app.Channel to com.sun.sgs.app.ServerChannel. The asymetry in the name confused me when I started to read the docs and it might be the same for a lot of people.
I have the same request to do with the ServerSession and the ClientSession, it would be nice if they had a common interface.
I also want to point the asymetry between the send functions of the ClientSession (that is using a SessionId to identify the receiver) and the ServerSession (that is using a ClientSession to identify the receiver).
Question: Why ?
Was it because you had a client team and a server team?</troll joke> ;D
Well I am just going to guess but I bet it has something to do with security. Aka the ClientSession object on the server contains the userid and the sessionId, the client on the other hand only has access to the sessionId. If your client has no issue providing the world with all your servers userids then you could certainly build something to distribute those to the clients. But if they had sent them out automattically and you had a need to conceal that kind of info you be out of luck…
Don’t get confused, the first argument of the send(…) functions are not sent on the network, they are just used as a way to point to/reference/identify the receiver of the message before the message is sent.
If just don’t get why there is currently a difference between the client API and the server API on those methods. It could be as simple to use a kind of SessionID on the server that it is on the client.
I would like to have some answers from the designers of the API, if possible.
Jeff, some words about this issue?
I understand, and I look forward to see any improvements to the API.
As a temporally fix, I created the missing common types in my lib JNAG, and I delegate the calls to the client OR the server in different subclasses. That’s a little ugly, but it works for now.
Hi, karmaGfa, I’m one of the developers who worked on that API. We spoke for awhile at GDC.
Good point! The short answer is: this is by design. Let’s take it in pieces:
1. Why do the server-side channels have more funtionality than the client-side channels?
Since this is the core SGS API, we want to include only the necessary functionality. We (or you!) can always build utilities to implement extra features, like letting clients join or leave channels directly. But if we put that into the core API, everyone would have to support it: all network wire protocols, and all client API implementations (even C++, Java Micro Edition, Flash, etc.).
The core operations let you send a client-to-server session message requesting a join, and your application logic can parse such a request and join the client to the channel. So while it makes sense to provide a utility for this, it doesn’t need to be in the core, so it isn’t.
Note that this decision has a design impact far beyond a couple of convenience methods. If the SGS API directly allowed clients to join or leave channels, we would also need to provide hooks for policy decisions (are all clients allowed to join any channel? None? Some?) and so on. Each bit of extra functionality can exponentially increase the complexity of the other pieces; we chose simplicity.
The main reason to keep it simple is so that we can make a lean, fast, scalable core.
2. Why don’t server-side channels inherit from the client-side channels (or from a common supertype)?
The server and client APIs are separate; we were careful to design them not to share anything.
The client API we provide is a reference implementation (and hopefully a very good one). But we allow any client that speaks the appropriate wire protocol to interoperate with the SGS server, so we don’t want to require Java client API implementations to extend a certain class for their session or channel representation, nor do we want the server to depend on a particular client API implementation detail.
Heh, not so much. In fact, the same set of individuals (myself included) designed the server-side IO and client-side IO interfaces, so these were all conscious decisions
Feel free to follow up with additional questions, and I’ll try to explain in more detail.
For your application, where you want to share objects between the client and server even though they don’t inherit from the same base class, you need to provide a common interface and write an adaptor class for the server side and client side to that interface. This is the approach taken in the MPK20 demo, and when that is open-sourced you can see exactly how that works; it sounds like you’re using a similar technique.
Sorry to bother you with my questions. :-X
I guess I love too much Java to stay quiet when I see places for improvements.
I understand and totally respect your choices since it was a design desicion.
As you said, I made some adaptors for the client and server and there is no problem at all.
