Server Based PLPTool Project

[Damon Cost]

I have begun working on a project with Dr. Sohoni here at ASU in which we are creating an interactive ebook for PLP and I have been tasked with the integration of the PLPTool.  Our goal is to have something similar in functionality to the 'playground' area on the okstate website where a student can be asked to type code into the browser ebook, except that we need full simulator functionality.  Ultimately we also want to create intelligent parsing that can recognize, and track, common mistakes and direct the student to appropriate sections of the ebook for further reading. Last year I was in a meeting with Wira where we discussed the desire to have PLPTool have a browser/server based option and I feel this project can essentially be the same thing; whether it be a desktop client, a browser, ebook, whatever, it should be able to communicate with the PLPTool, running on a server, in the same manner.  The thought then was to have the PLPTool create a log of all events during simulation and package the log as an xml file that would be used to pass information between client and server, therefore, this is how I plan to implement this project.  The reason for this post is to just give the PLP community a heads-up about what we are doing and to create a discussion about any ideas for implementation that anyone has or anything that they would like to see included.  

Thanks all.

[vasu gupta]

I would recommend communication of server and the client to be JSON based, in my opinion it will be faster and lighter than xml for this.

Thanks,

Vasu 

[Sohum Sohoni]

Sounds great. Is there any downside to using JSON? Would xml be more universal?

Sohum

--
You received this message because you are subscribed to the Google Groups "progressive-learning-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to progressive-learning...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vasu gupta]

I can't really point out a downside, there has been a good amount of JSON usage recently by web developers for data exchange. That being said, one concern that I know of and developers using JSON often have is that not very human readable when compared to xml. But in the end, the code has to read it so its not much of an issue, the developer should maintain good document that can explain the JSON the server/client side spits out. It is also beneficial for other team members to make sense of the large humongous strings.

I suggested JSON because last time I met the team, we concluded that the amount of data we are going to spit out in logging is going to be large and we want to communicate it between the client and server as the user interacts. So you dont want to make heavy transactions otherwise you will have ugly delays in user interaction. Web browser development teams are pushing limits (chrome's V8 engine) in getting browsers that can chew a large amount of JavaScript (JSON parsed using JavaScript) and as I mentioned earlier, JSON is light (minimum overhead).. 

If the design has changed from what we discussed (we didnt have a fix architecture but we made some calculations) then the above can be scrapped and there is a need to re evaluate options for data communication between the serve and client.

Thanks,

Vasu

[Wira Mulia]

I have been thinking about this and wrote a document of a possible web engine architecture to support this:

http://wmulia.org/plp/webengine.html

The primary consideration is to have a system where you can support multiple use-cases. For example, the system can be used to create an interactive e-book, a development environment, and a collaborative session. You may ask why don't we have separate programs for all these? The answer is that there are certain commonalities between these use cases that can be solved by using something like HTML5 (static presentation + dynamic components with RESTful API). For example, all three use cases will need a development component where the user can interactively compile/assemble. The difference would be how this component is presented.

I organized the architecture this way so it should be easier to divide and conquer and people to take ownership of small or big pieces, as long as the interfaces are well defined.

I started the PLP Web component on the repo few months ago. It currently does nothing much, but it can serve up a barebone development/editor page where you can assemble your program from the web browser. (it's under reference/sw/PLPWeb)

You can build it with ant (or use netbeans), and run it with java -jar PLPWeb.jar. Only the test server works right now.

[Sohum Sohoni]

Hi Wira (and others),

The web engine architecture looks great! I was wondering if we should have a google hangout next week to talk about this. Everyone interested can join in. We will also make sure that a synopsis of the meeting is posted to the mailing list so that others can follow along. I will talk to Damon and set up a time for the hangout. If any of you have a preference for a day/time, please send me an email by Friday evening.

Thanks,

Sohum

[Siddharth]

While reading the discussion I noticed someone mentioning that there would be a lot of data. I would say we should start with minimal data and have a special "switch" something like a log mode or debug to produce the logs or extra data only when required.

---

From: Sohum Sohoni
Sent: ‎8/‎20/‎2014 2:52 PM
To: progressive-le...@googlegroups.com
Subject: Re: [PLP 290] Re: Server Based PLPTool Project