rails-devel

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[brett l. <wak...@gm...>]

Moving this thread over to the appropriate list....   ;-)


On Tue, Aug 5, 2008 at 12:18 PM, Erik Vos <eri...@hc...> wrote:
>> But all considered what I would really like to see, are
>> online play capabilities added to Rail for remote real time playing.
>> That would be a real breakthrough in the hobby.
>
> Online play is certainly in scope for Rails, but I can't tell when it will
> happen.
> I'm currently the only (somewhat) active developer, and these days other
> hobby and non-hobby activities take most of my time.
>
> I'm actually on a crossroads as how to proceed with Rails. I could first
> work towards completion of some half-done games (1856, 1835, 1870) in the
> current (hot-seat only) version (earlier this year some interest in 1856 has
> surfaced). That is the easy road.
>
> I could also start working towards a version that would allow on-line play
> in some form or shape. As we already have a complete graphical interface
> programmed in Java, the simplest approach might be to split the existing
> system in a client and a server part (in fact, I already have been gradually
> working towards such a split for the last 2 years, but it is far from done).
> For the user interface this could lead to either a Java client program, to
> be installed on local PCs, or a Java applet, that could be accessed over the
> Web. However, Java applets are notorious for their long download and
> initialization times, so I don't know if working with such an applet would
> be an appealing foresight for many people.
>

My preference would be to finish off the games we've partially
implemented, get a "base" set of games into a playable state, and then
move on to doing the client/server split.

However, if you're eager to move on to more interesting work, we can
always come back to adding more games later. ;-)


> There are several ways in which a local client program could communicate
> with a central server. One perhaps unusual way could be near-real time
> communication via SMTP/POP3 (e-mail) - this way we could have PBEM as an
> extra bonus. Not sure if other communication methods are so easy as they
> sound - having a server listening on an Internet port has security
> implications that I can't assess - I'm a novice in that matter.
>

If we want to leverage some existing code, for the "near realtime"
communication, XMPP (aka. Jabber) is a more appropriate protocol. I
believe there are a few different existing libraries we can leverage
for the communications, which could save us a TON of work.

We should consider SMTP to be for PBEM only.  To be honest, the PBEM
component can be as simple as dropping the saved game file into an
e-mail, and passing around the saved game files.  There's a PBEM
Diplomacy client that does basically this. It connects to your mail
server and just looks for specially formatted e-mails, and loads the
contents into the game engine.

> Apologies to those who find this post a bit too technical. The technical
> details can better be discussed in the Sourceforge Rails maillist, or in the
> 18xx-softdev Yahoo group. But I'm now mainly interested in thoughts on the
> general line of development that Rails might take in the near future.
>
> Erik.
>
>

---Brett.

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[Erik V. <eri...@hc...>]

> If we want to leverage some existing code, for the "near realtime"
> communication, XMPP (aka. Jabber) is a more appropriate protocol. I
> believe there are a few different existing libraries we can leverage
> for the communications, which could save us a TON of work.

XML simple? It's verbose and slow, and needs lots of code to build and
parse, as I have experienced so far...   Its main asset is that it's
readable (and, oh yes, fashionable).

The simplest thing IMO would be to pass on serialized java objects.
Save/Load is already based on (de)serialization. It's simple and fast and it
works.

My question is rather how to transfer such serialized objects between client
and server, or applet and server, or whatever.
 
> We should consider SMTP to be for PBEM only.  To be honest, the PBEM
> component can be as simple as dropping the saved game file into an
> e-mail, and passing around the saved game files.  There's a PBEM
> Diplomacy client that does basically this. It connects to your mail
> server and just looks for specially formatted e-mails, and loads the
> contents into the game engine.

I had such a thing in mind. I suppose there must be Java code around for a
very basic SMTP/POP3 client, that we can build into Rails.

Now, if we put either the ASCIIfied serialized Java objects or the
corresponding plain text (or why not both) into e-mails, we might have
achieved PBEM and near real-time play by the same mechanism.

This would be just a start, other means can perhaps be added later.

On a LAN it can of course be done a lot simpler: just open a stream between
client and server and pass the objects around. But is that safe enough for
Internet?


Erik.

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[brett l. <wak...@gm...>]

On Wed, Aug 6, 2008 at 3:30 PM, Erik Vos <eri...@hc...> wrote:
>> If we want to leverage some existing code, for the "near realtime"
>> communication, XMPP (aka. Jabber) is a more appropriate protocol. I
>> believe there are a few different existing libraries we can leverage
>> for the communications, which could save us a TON of work.
>
> XML simple? It's verbose and slow, and needs lots of code to build and
> parse, as I have experienced so far...   Its main asset is that it's
> readable (and, oh yes, fashionable).
>

Not plain XML.   XMPP. There's a difference. XMPP has it's own IETF
standards and definitions.

There are already libraries ( http://www.jabber.org/libraries ) for
several languages, so most of the details of how to send messages is
already done for us.

In general, XMPP is a fairly mature communication protocol that is
excellent for real-time communications and message passing.. Plus, it
would be trivial to include a chat feature into the game. :-)

I'm not saying this is the only option, just that's its available and
worth considering.

> The simplest thing IMO would be to pass on serialized java objects.
> Save/Load is already based on (de)serialization. It's simple and fast and it
> works.
>

Sure, that works too.  Java has a bunch of API options for
client/server communications.  The down side is that we'd be forced to
build more of the structure ourself, and that will also require more
debugging effort than just hooking into a pre-existing library.

Sometimes, DIY is still the best way to go. I do want to point out the
added costs of going this route, though.

> My question is rather how to transfer such serialized objects between client
> and server, or applet and server, or whatever.
>
>> We should consider SMTP to be for PBEM only.  To be honest, the PBEM
>> component can be as simple as dropping the saved game file into an
>> e-mail, and passing around the saved game files.  There's a PBEM
>> Diplomacy client that does basically this. It connects to your mail
>> server and just looks for specially formatted e-mails, and loads the
>> contents into the game engine.
>
> I had such a thing in mind. I suppose there must be Java code around for a
> very basic SMTP/POP3 client, that we can build into Rails.
>
> Now, if we put either the ASCIIfied serialized Java objects or the
> corresponding plain text (or why not both) into e-mails, we might have
> achieved PBEM and near real-time play by the same mechanism.
>

Let's be _really_ clear about this.  SMTP is NOT anything resembling a
real-time communication protocol. There are mechanisms built into the
protocol that assume a highly variable amount of latency.

While SMTP is capable of fast transmission, that delivery speed is
never guaranteed. Delivery speed is not even a significant part of the
RFC. There's simply no way to guarantee that messages are delivered in
a timely fashion.

SMTP really needs to be considered as a PBEM-only protocol.  For more
real-time play we absolutely must use a different protocol.

What we're ultimately going to need is a modular network design that
allows us to "plug in" multiple communication backends, and define
whether they.are for live network play or "PBEM" play.


> This would be just a start, other means can perhaps be added later.
>
> On a LAN it can of course be done a lot simpler: just open a stream between
> client and server and pass the objects around. But is that safe enough for
> Internet?
>

These days, LAN play and Internet play are one and the same. We really
shouldn't separate them.  At a basic level, both types of play will
use TCP or UDP and should be indistinguishable from the other. (I
can't think of any reason why this wouldn't be the case.)

If we're going to implement our own communication method, it may be
good to use an encrypted communication channel. I believe Java has
some secure communication options, or we can use the openssl libraries
to encrypt our messages prior to transmission. Although, it also comes
down to what exactly it is that we're sending over the wire. We may be
able to get away with basic authentication without requiring a fully
encrypted channel for communicating.


>
> Erik.
>


----Brett.

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[Erik V. <eri...@hc...>]

What we need for "real" real-time play is some API that can, both on the
server and the client side, take a Java object (or a series of objects) and
deliver it to the other side by whatever magic. The difference between the
client API and the server API is, that the former opens outgoing connections
and the latter accepts incoming connections. For the rest it must be a
asynchronous two-way channel.

If Jabber can deliver such a black box, or if we can easily build such APIs
on top of Jabber, fine with me.

I've done a quick search on Jabber. So far I have only seen glimpses of APIs
at the client side. Is there also a java API that we can bolt on our server
(the 18xx game engine)? Or would our server be just another Jabber client?

During my brief search I have seen remarks on large overhead (what else do
you expect with XML) and problems with binary data, so I'm not immediately
convinced of the greatness of this technology. But perhaps I'm wrong.

In any case: I don't want another batik.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: Thursday 07 August 2008 01:49
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)
> 
> On Wed, Aug 6, 2008 at 3:30 PM, Erik Vos <eri...@hc...> wrote:
> >> If we want to leverage some existing code, for the "near realtime"
> >> communication, XMPP (aka. Jabber) is a more appropriate protocol. I
> >> believe there are a few different existing libraries we 
> can leverage
> >> for the communications, which could save us a TON of work.
> >
> > XML simple? It's verbose and slow, and needs lots of code 
> to build and
> > parse, as I have experienced so far...   Its main asset is that it's
> > readable (and, oh yes, fashionable).
> >
> 
> Not plain XML.   XMPP. There's a difference. XMPP has it's own IETF
> standards and definitions.
> 
> There are already libraries ( http://www.jabber.org/libraries ) for
> several languages, so most of the details of how to send messages is
> already done for us.
> 
> In general, XMPP is a fairly mature communication protocol that is
> excellent for real-time communications and message passing.. Plus, it
> would be trivial to include a chat feature into the game. :-)
> 
> I'm not saying this is the only option, just that's its available and
> worth considering.
> 
> > The simplest thing IMO would be to pass on serialized java objects.
> > Save/Load is already based on (de)serialization. It's 
> simple and fast and it
> > works.
> >
> 
> Sure, that works too.  Java has a bunch of API options for
> client/server communications.  The down side is that we'd be forced to
> build more of the structure ourself, and that will also require more
> debugging effort than just hooking into a pre-existing library.
> 
> Sometimes, DIY is still the best way to go. I do want to point out the
> added costs of going this route, though.
> 
> > My question is rather how to transfer such serialized 
> objects between client
> > and server, or applet and server, or whatever.
> >
> >> We should consider SMTP to be for PBEM only.  To be 
> honest, the PBEM
> >> component can be as simple as dropping the saved game file into an
> >> e-mail, and passing around the saved game files.  There's a PBEM
> >> Diplomacy client that does basically this. It connects to your mail
> >> server and just looks for specially formatted e-mails, and 
> loads the
> >> contents into the game engine.
> >
> > I had such a thing in mind. I suppose there must be Java 
> code around for a
> > very basic SMTP/POP3 client, that we can build into Rails.
> >
> > Now, if we put either the ASCIIfied serialized Java objects or the
> > corresponding plain text (or why not both) into e-mails, we 
> might have
> > achieved PBEM and near real-time play by the same mechanism.
> >
> 
> Let's be _really_ clear about this.  SMTP is NOT anything resembling a
> real-time communication protocol. There are mechanisms built into the
> protocol that assume a highly variable amount of latency.
> 
> While SMTP is capable of fast transmission, that delivery speed is
> never guaranteed. Delivery speed is not even a significant part of the
> RFC. There's simply no way to guarantee that messages are delivered in
> a timely fashion.
> 
> SMTP really needs to be considered as a PBEM-only protocol.  For more
> real-time play we absolutely must use a different protocol.
> 
> What we're ultimately going to need is a modular network design that
> allows us to "plug in" multiple communication backends, and define
> whether they.are for live network play or "PBEM" play.
> 
> 
> > This would be just a start, other means can perhaps be added later.
> >
> > On a LAN it can of course be done a lot simpler: just open 
> a stream between
> > client and server and pass the objects around. But is that 
> safe enough for
> > Internet?
> >
> 
> These days, LAN play and Internet play are one and the same. We really
> shouldn't separate them.  At a basic level, both types of play will
> use TCP or UDP and should be indistinguishable from the other. (I
> can't think of any reason why this wouldn't be the case.)
> 
> If we're going to implement our own communication method, it may be
> good to use an encrypted communication channel. I believe Java has
> some secure communication options, or we can use the openssl libraries
> to encrypt our messages prior to transmission. Although, it also comes
> down to what exactly it is that we're sending over the wire. We may be
> able to get away with basic authentication without requiring a fully
> encrypted channel for communicating.
> 
> 
> >
> > Erik.
> >
> 
> 
> ----Brett.
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[brett l. <wak...@gm...>]

On Thu, Aug 7, 2008 at 1:07 PM, Erik Vos <eri...@hc...> wrote:
> What we need for "real" real-time play is some API that can, both on the
> server and the client side, take a Java object (or a series of objects) and
> deliver it to the other side by whatever magic. The difference between the
> client API and the server API is, that the former opens outgoing connections
> and the latter accepts incoming connections. For the rest it must be a
> asynchronous two-way channel.
>
> If Jabber can deliver such a black box, or if we can easily build such APIs
> on top of Jabber, fine with me.
>
> I've done a quick search on Jabber. So far I have only seen glimpses of APIs
> at the client side. Is there also a java API that we can bolt on our server
> (the 18xx game engine)? Or would our server be just another Jabber client?
>

If we use XMPP, the server-side would be just another jabber server,
and people could use any jabber server they want.  This has some
advantages, because we can then leverage things like Jabber.org and
google talk as ways of connecting our clients.

However, doing a "basic" client/server application is relatively
simple:  http://williams.comp.ncat.edu/Networks/JavaSocketExample.htm


> During my brief search I have seen remarks on large overhead (what else do
> you expect with XML) and problems with binary data, so I'm not immediately
> convinced of the greatness of this technology. But perhaps I'm wrong.

Like I said, it's just an option that is worth consideration.  There's
more than one way to solve this problem.  :-)

> In any case: I don't want another batik.
>

I'm not sure I understand what you're referring to there.

> Erik.
>


---Brett.


>> -----Original Message-----
>> From: rai...@li...
>> [mailto:rai...@li...] On Behalf
>> Of brett lentz
>> Sent: Thursday 07 August 2008 01:49
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)
>>
>> On Wed, Aug 6, 2008 at 3:30 PM, Erik Vos <eri...@hc...> wrote:
>> >> If we want to leverage some existing code, for the "near realtime"
>> >> communication, XMPP (aka. Jabber) is a more appropriate protocol. I
>> >> believe there are a few different existing libraries we
>> can leverage
>> >> for the communications, which could save us a TON of work.
>> >
>> > XML simple? It's verbose and slow, and needs lots of code
>> to build and
>> > parse, as I have experienced so far...   Its main asset is that it's
>> > readable (and, oh yes, fashionable).
>> >
>>
>> Not plain XML.   XMPP. There's a difference. XMPP has it's own IETF
>> standards and definitions.
>>
>> There are already libraries ( http://www.jabber.org/libraries ) for
>> several languages, so most of the details of how to send messages is
>> already done for us.
>>
>> In general, XMPP is a fairly mature communication protocol that is
>> excellent for real-time communications and message passing.. Plus, it
>> would be trivial to include a chat feature into the game. :-)
>>
>> I'm not saying this is the only option, just that's its available and
>> worth considering.
>>
>> > The simplest thing IMO would be to pass on serialized java objects.
>> > Save/Load is already based on (de)serialization. It's
>> simple and fast and it
>> > works.
>> >
>>
>> Sure, that works too.  Java has a bunch of API options for
>> client/server communications.  The down side is that we'd be forced to
>> build more of the structure ourself, and that will also require more
>> debugging effort than just hooking into a pre-existing library.
>>
>> Sometimes, DIY is still the best way to go. I do want to point out the
>> added costs of going this route, though.
>>
>> > My question is rather how to transfer such serialized
>> objects between client
>> > and server, or applet and server, or whatever.
>> >
>> >> We should consider SMTP to be for PBEM only.  To be
>> honest, the PBEM
>> >> component can be as simple as dropping the saved game file into an
>> >> e-mail, and passing around the saved game files.  There's a PBEM
>> >> Diplomacy client that does basically this. It connects to your mail
>> >> server and just looks for specially formatted e-mails, and
>> loads the
>> >> contents into the game engine.
>> >
>> > I had such a thing in mind. I suppose there must be Java
>> code around for a
>> > very basic SMTP/POP3 client, that we can build into Rails.
>> >
>> > Now, if we put either the ASCIIfied serialized Java objects or the
>> > corresponding plain text (or why not both) into e-mails, we
>> might have
>> > achieved PBEM and near real-time play by the same mechanism.
>> >
>>
>> Let's be _really_ clear about this.  SMTP is NOT anything resembling a
>> real-time communication protocol. There are mechanisms built into the
>> protocol that assume a highly variable amount of latency.
>>
>> While SMTP is capable of fast transmission, that delivery speed is
>> never guaranteed. Delivery speed is not even a significant part of the
>> RFC. There's simply no way to guarantee that messages are delivered in
>> a timely fashion.
>>
>> SMTP really needs to be considered as a PBEM-only protocol.  For more
>> real-time play we absolutely must use a different protocol.
>>
>> What we're ultimately going to need is a modular network design that
>> allows us to "plug in" multiple communication backends, and define
>> whether they.are for live network play or "PBEM" play.
>>
>>
>> > This would be just a start, other means can perhaps be added later.
>> >
>> > On a LAN it can of course be done a lot simpler: just open
>> a stream between
>> > client and server and pass the objects around. But is that
>> safe enough for
>> > Internet?
>> >
>>
>> These days, LAN play and Internet play are one and the same. We really
>> shouldn't separate them.  At a basic level, both types of play will
>> use TCP or UDP and should be indistinguishable from the other. (I
>> can't think of any reason why this wouldn't be the case.)
>>
>> If we're going to implement our own communication method, it may be
>> good to use an encrypted communication channel. I believe Java has
>> some secure communication options, or we can use the openssl libraries
>> to encrypt our messages prior to transmission. Although, it also comes
>> down to what exactly it is that we're sending over the wire. We may be
>> able to get away with basic authentication without requiring a fully
>> encrypted channel for communicating.
>>
>>
>> >
>> > Erik.
>> >
>>
>>
>> ----Brett.
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK &
>> win great prizes
>> Grand prize is a trip for two to an Open Source event
>> anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[Erik V. <eri...@hc...>]

 

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: Thursday 07 August 2008 21:35
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)
> 
> On Thu, Aug 7, 2008 at 1:07 PM, Erik Vos <eri...@hc...> wrote:
> > What we need for "real" real-time play is some API that 
> can, both on the
> > server and the client side, take a Java object (or a series 

> If we use XMPP, the server-side would be just another jabber server,
> and people could use any jabber server they want.  This has some
> advantages, because we can then leverage things like Jabber.org and
> google talk as ways of connecting our clients.

OK, so the game engine (acting as the GM) will also be a jabber client.
 
> However, doing a "basic" client/server application is relatively
> simple:  http://williams.comp.ncat.edu/Networks/JavaSocketExample.htm

Yes, I know. A while ago I have developed a fairly elaborate comms package
based on such principles.
In fact I have in mind to reuse it here in some form. 
But then the game enogine will be a server listening to some port, open to
everyone.
That's fine on a LAN, but is this secure enough for the Internet, even with
basic authentication? I doubt.
 
> > In any case: I don't want another batik.
> >
> 
> I'm not sure I understand what you're referring to there.

Its enormous size - and so many libraries that call each other and that all
need to be mentioned in the classpath....

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[brett l. <wak...@gm...>]

On Thu, Aug 7, 2008 at 2:08 PM, Erik Vos <eri...@hc...> wrote:
>
>
>> -----Original Message-----
>> From: rai...@li...
>> [mailto:rai...@li...] On Behalf
>> Of brett lentz
>> Sent: Thursday 07 August 2008 21:35
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)
>>
>> On Thu, Aug 7, 2008 at 1:07 PM, Erik Vos <eri...@hc...> wrote:
>> > What we need for "real" real-time play is some API that
>> can, both on the
>> > server and the client side, take a Java object (or a series
>
>> If we use XMPP, the server-side would be just another jabber server,
>> and people could use any jabber server they want.  This has some
>> advantages, because we can then leverage things like Jabber.org and
>> google talk as ways of connecting our clients.
>
> OK, so the game engine (acting as the GM) will also be a jabber client.
>

Yes.  The "server" component would function as a moderator and as a
message relay for distributing game data to the players.  In that
sense, it's still a server, but from the messaging layer's perspective
it's a jabber client.

>> However, doing a "basic" client/server application is relatively
>> simple:  http://williams.comp.ncat.edu/Networks/JavaSocketExample.htm
>
> Yes, I know. A while ago I have developed a fairly elaborate comms package
> based on such principles.
> In fact I have in mind to reuse it here in some form.
> But then the game enogine will be a server listening to some port, open to
> everyone.
> That's fine on a LAN, but is this secure enough for the Internet, even with
> basic authentication? I doubt.
>

Well, this is where I'm on much more familiar ground. I've got a fair
amount of experience with networking and network security.

When it comes to security, there's a couple of things that we may want
to assure.  It breaks down like this:

1. Application security
2. Player authentication and authorization
3. Transport security.

App security is simply making sure that a remote user can't do
anything malicious to the client or server. The major risk factor for
our application is remote file system access. We tend to cover this by
not allowing the user to specify files or paths outside of the config
file, and the app only reads the config files and doesn't write to
them.  Also, we don't really allow any form of remote code execution,
so we're fairly safe here.

Player authentication is something that I see as mandatory. At a
minimum, we will need to provide the users with a way to
password-protect their server.  An optional step beyond that is
setting specific passwords for individual players, or specific IP
allow/deny lists.  I can't really see the need for privilege
delegation, because our application usage is fairly simple.

Transport security is, to me, optional. Not using SSL/TLS introduces
some risk of game tampering due to packet modification or injection.
However, I don't really see this as a significant risk, because it can
be mitigated within the game engine itself by doing value boundary
checking, checksumming the messages, etc.  The other reason I consider
this optional is because we're not seeking to communicate privileged
information. At best, we'll be sending the player's names over the
wire, along with the updated game data. I would expect the players to
be smart enough to not use their full names when playing internet
games.


>> > In any case: I don't want another batik.
>> >
>>
>> I'm not sure I understand what you're referring to there.
>
> Its enormous size - and so many libraries that call each other and that all
> need to be mentioned in the classpath....
>

Hrm. I'm not sure I see the problem.

Java isn't exactly known to be a "lightweight" language. The JVM
itself is considered pretty bloated.

To be honest, if code size was a legitimate issue, we should be
writing significant portions of this app in C or assembly.

Also, Batik is broken up by function. We only use a couple things, and
can definitely delete the libraries we're not using.

---Brett.

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[Erik V. <eri...@hc...>]

> > OK, so the game engine (acting as the GM) will also be a 
> jabber client.
> >
> 
> Yes.  The "server" component would function as a moderator and as a
> message relay for distributing game data to the players.  In that
> sense, it's still a server, but from the messaging layer's perspective
> it's a jabber client.

I like that concept. Will certainly have a closer look at Jabber later on.
Not having to set up a comms server saves a lot of trouble.
Security looks a lot simpler that way.
 
Erik.

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[Jeffrey B. M. <mc...@br...>]

On Sat, Aug 09, 2008 at 08:44:13PM +0200, Erik Vos wrote:
> 
> I like that concept. Will certainly have a closer look at Jabber later on.
> Not having to set up a comms server saves a lot of trouble.
> Security looks a lot simpler that way.

For a point of reference, VASSAL's messaging is at least partway Jabber
underneath (I don't remember if they ever finished the conversion)

Jeff

-- 
----------------------------------------------------------------------------
"The man who does not read good books has no advantage over 
 the man who cannot read them."
 -- Mark Twain
----------------------------------------------------------------------------

Re: [Rails-devel] [18xx] Rails (was: Web-based 18xx)

[Dave M. <da...@mi...>]

On 8/6/2008 06:30 PM, Erik Vos wrote:
> > If we want to leverage some existing code, for the "near realtime"
> > communication, XMPP (aka. Jabber) is a more appropriate protocol. I
> > believe there are a few different existing libraries we can leverage
> > for the communications, which could save us a TON of work.
>
>XML simple? It's verbose and slow, and needs lots of code to build and
>parse, as I have experienced so far...   Its main asset is that it's
>readable (and, oh yes, fashionable).
>
>The simplest thing IMO would be to pass on serialized java objects.
>Save/Load is already based on (de)serialization. It's simple and fast and it
>works.
>
>My question is rather how to transfer such serialized objects between client
>and server, or applet and server, or whatever.
>
>...
>
>Erik.

I don't know what other mechanisms have been considered, but
Sun's JINI can pass objects. and deal with the clienr/server issues.

I spent a few months trying to learn it but gave up when other 
opportunities arose.
It tapped into a lot of heavy weight distributed communication 
features that I recognized their value from my software development 
experience, but found a bit daunting to learn all at once in a new platform.

It's more of a framework than a package.

FWIW...

Dave. 

Re: [Rails-devel] [18xx] Rails

[Erik V. <eri...@hc...>]

Hi John,

That sounds like an interesting option. How is client-server communication
organized in this concept?
A problem we would have with plain HTTP is, that the server will send
unsolicited messages (i.e. updates from moves by other players).

I think this could be a further development, after we have split off our
current UI to a separate client.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of John A. Tamplin
> Sent: Wednesday 06 August 2008 20:51
> To: Dev...@sc...; 
> li...@sc...; 
> fo...@sc...; 
> "Ra...@sc...":an 18xx game
> Subject: Re: [Rails-devel] [18xx] Rails
> 
> On Tue, Aug 5, 2008 at 12:18 PM, Erik Vos <eri...@hc...> wrote:
> 
> > I could also start working towards a version that would 
> allow on-line play
> > in some form or shape. As we already have a complete 
> graphical interface
> > programmed in Java, the simplest approach might be to split 
> the existing
> > system in a client and a server part (in fact, I already 
> have been gradually
> > working towards such a split for the last 2 years, but it 
> is far from done).
> > For the user interface this could lead to either a Java 
> client program, to
> > be installed on local PCs, or a Java applet, that could be 
> accessed over the
> > Web. However, Java applets are notorious for their long download and
> > initialization times, so I don't know if working with such 
> an applet would
> > be an appealing foresight for many people.
> >   
> Another option is Google Web Toolkit for the client side.  You can't 
> take the existing UI code and port it, but you can write in a 
> familiar 
> style and then have the GWT compiler translate it to 
> Javascript to run 
> in the browser.  Now applets to download, no requirement to have Java 
> installed, etc.  If you are interested in further discussion 
> about it, I 
> would be happy to fill in the details as I work on it for Google.
> 
> --
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] [18xx] Rails

[John A. T. <jat...@ja...>]

On Thu, 7 Aug 2008, Erik Vos wrote:

> That sounds like an interesting option. How is client-server communication
> organized in this concept?

It looks like normal Java RPC, except that the RPC is async (ie, you get 
callbacks when it returns).

> A problem we would have with plain HTTP is, that the server will send
> unsolicited messages (i.e. updates from moves by other players).

This can be done with Comet or hanging gets.

One other benefit I didn't menion is that you can debug the client code in 
Eclipse (or other IDE) as easily as your server code.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] [18xx] Rails

[brett l. <wak...@gm...>]

On Thu, Aug 7, 2008 at 2:01 PM, John A. Tamplin <jat...@ja...> wrote:
> On Thu, 7 Aug 2008, Erik Vos wrote:
>
>> That sounds like an interesting option. How is client-server communication
>> organized in this concept?
>
> It looks like normal Java RPC, except that the RPC is async (ie, you get
> callbacks when it returns).
>
>> A problem we would have with plain HTTP is, that the server will send
>> unsolicited messages (i.e. updates from moves by other players).
>
> This can be done with Comet or hanging gets.
>
> One other benefit I didn't menion is that you can debug the client code in
> Eclipse (or other IDE) as easily as your server code.
>


The down side, of course, is that we'd need to rewrite all of the GUI
code.  The GUI code isn't great, but it's currently functioning enough
to be usable.

Unless John is volunteering to do the porting, I don't really see
where this suggestion moves the project forward. Tossing out our
currently functioning GUI code and redoing the same thing over again
rather than working on either adding new features or improving
existing capability just doesn't seem very productive to me.


> --
> John A. Tamplin                                 ja...@ja...
> 770/436-5387 HOME                               4116 Manson Ave
>                                                Smyrna, GA  30082-3723
>


---Brett.

Re: [Rails-devel] [18xx] Rails

[John A. T. <ja...@ja...>]

On Thu, 7 Aug 2008, brett lentz wrote:

> The down side, of course, is that we'd need to rewrite all of the GUI
> code.  The GUI code isn't great, but it's currently functioning enough
> to be usable.
>
> Unless John is volunteering to do the porting, I don't really see
> where this suggestion moves the project forward. Tossing out our
> currently functioning GUI code and redoing the same thing over again
> rather than working on either adding new features or improving
> existing capability just doesn't seem very productive to me.

I was just offering an alternative to Java applets, which I believe would 
entail signicant changes to the UI anyway, but I agree it would be better 
to add network play to the existing code and just require people to run a 
jar from the command line if they want to play.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Rails

[Erik V. <eri...@xs...>]

Done.

 

From: sco...@gm... [mailto:sco...@gm...] On Behalf
Of Scott Petersen
Sent: Thursday, October 27, 2011 2:43 PM
To: Erik Vos
Subject: Rails

 

Erik,

 

Feel free to remove my 18Jr prototype from Rails.  I never updated to egit
and I probably won't in the near future.

 

Scott

Re: [Rails-devel] [18xx] Rails

[John A. T. <ja...@ja...>]

On Tue, Aug 5, 2008 at 12:18 PM, Erik Vos <eri...@hc...> wrote:

> I could also start working towards a version that would allow on-line play
> in some form or shape. As we already have a complete graphical interface
> programmed in Java, the simplest approach might be to split the existing
> system in a client and a server part (in fact, I already have been gradually
> working towards such a split for the last 2 years, but it is far from done).
> For the user interface this could lead to either a Java client program, to
> be installed on local PCs, or a Java applet, that could be accessed over the
> Web. However, Java applets are notorious for their long download and
> initialization times, so I don't know if working with such an applet would
> be an appealing foresight for many people.
>   
Another option is Google Web Toolkit for the client side.  You can't 
take the existing UI code and port it, but you can write in a familiar 
style and then have the GWT compiler translate it to Javascript to run 
in the browser.  Now applets to download, no requirement to have Java 
installed, etc.  If you are interested in further discussion about it, I 
would be happy to fill in the details as I work on it for Google.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723