Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

It works for me.

6 (31.6%)

It does not work for me.

1 (5.3%)

I'd be willing to help test it.

6 (31.6%)

I'm not interested in testing it.

1 (5.3%)

I might be willing to help test it.

5 (26.3%)

Total Members Voted: 14

[Angle]

 Mmm, fair enough. I'll leave it up anyway, just in case anyone is interested.

[Angle]

Alright, so I'm looking at Grails, and it looks pretty good. I haven't wrapped my head around it yet, it's pretty mind blowing, but I'm gonna go over it and see if it does what we want.

[Angle]

Turns out grails is more for apps to be used within a company, they have to be downloaded and installed. I think I can get the java working more or less the way we had it, without needing to edit the policy file. It says that "They can make network connections to the host and port they came from. Protocols must match, and if a domain name is used to load the applet, the domain name must be used to connect back to the host, not the IP address." I think I can make that work somehow. I haven't got it yet though.

[Antsan]

I don't know whether this is workable for what you are doing, but in "Land of Lisp" a lisp server is used to run a game of Risk. The image was drawn on the server and sent as an svg to the client.

[dorf]

Well, an image can be generated in any language on the backend, not only Lisp. But it's an interesting idea!

But what should Angle do when a single thread (graph) is HUGE? Serve a HUGE image, or make the posts unreadably small?
Also, what happens to the interactivity of the application? Sending plain data to browser and letting the browser visualize and modify can offer much better user control. And uses less bandwidth.

If this is considered a prototype with intention of rewriting later, using the simplest of methods will probably be best.

[Angle]

Sending the data is relatively easy, it's establishing a connection that's difficult.

[Anvilfolk]

Yeah, the increased security in the JVM is making it increasingly hard to establish socket connections when programming web applications.

I don't think the same is true if you're just running a Java application locally. There you can easily open a socket connection to somewhere else.

And yeah, dorf, the idea is definitely that you'll simply send the data, and the client will interpret it and show it to the user. Sending images would be very unoptimal for large graphs/debates!

[Antsan]

Well, that was to be expected.

[Angle]

Alright, I think I have this figured out - I just need to convert the server into a servlet, which doesn't look too hard.

[Angle]

I'm quitting my job so I can find time to work on this again, so things should start moving again. Do you guys think we should see about sticking a copyleft license of some sort on it? We haven't really been bothering with that. I think we kicked the idea around a few times and never really got around to it.

[Angle]

well, I managed to figure out how to get the HttpServlet going, and that was pretty easy. I had a lot of trouble getting Tomcat installed and running, and some more getting my HttpServlet installed, but I worked it out in the end. Now I need to figure out how to get the actual meat of JAgoraServer turned into a servlet, which may be more difficult than I had anticipated. I'm thinking I'll use the facilities for Websocket servlets. Does that sound like a reasonable idea? I'm also considering getting rid of the client applet altogether and having he entire response be stuffed into HTML and JavaScript. That would be a pretty significant project, though...

[Anvilfolk]

I'm afraid I am not familiar at all with most of these web technologies, sorry! I'd say that unless you find a way to send binary data, i.e. BSON, then it's going to be a fair amount of work to rework the server part of Agora.

[Angle]

Alright, so I'm getting pretty well along. I finished the first draft for the server, and I'm working on the client now. I'm doing some pretty significant refactoring, though - I turned JAgoraServer into JAgoraSocketServer and created an interface called JAgoraserver, which the socket server and the websocket servlet both extend. I'm also turning IJAgoraLib into an abstract class and moving much of JAgoraLib's functionality there - all of the construct and parse methods - so as to avoid duplicating them in JAgoraWebSocketLib. Sound alright?

[Anvilfolk]

I'm just a bit worried that we're replicating a ton of work. Is there a way that we can separate the delivery method (raw sockets vs HTTP) but not the payload (JSON/BSON)?

[Angle]

Yeah, that's what I did. That's why I moved a bunch of methods to IJAgoraLib. So that don't need to have two copies in both JAgoraLib ad JAgoraWebSocketLib. The only thing that should matter is how the binary data is sent from place to place, after that, all the same methods are used to parse and respond to it.