Dynamic Scoped Objects

Previously, we gave you a teaser about a whole new level of functionality in OLab4: Scoped Objects. These have turned out to be powerful and will allow much improved reusability of modules and objects, which will speed up case authoring.

Being able to control the scope means that, like in common programming languages, where variables can be local, public, global etc, our objects can also be shared across a variety of levels eg map-level, server-level but also node-level and global-level ( a common set to be shared by all OLab4 servers).

Until recently, the state of some of the objects, like Counters, was only updated when the user changed Nodes. This is somewhat similar to the situation in OLab3. While this concept is nice and simple, it does have lots of limitations.

The new Single Page Architecture (SPA) in OLab4 means that some Counters can be manipulated within the page. It will be easier to illustrate what this means with some example cases when OLab4 is ready.

Now, our development team has come up with the concept of Dynamic Scoped Objects. These can be changed, without having to change Nodes, and server load can be controlled so that complex cases do not bog things down.

For server-level Counters, that will be used in team-based learning, this also opens up some interesting possibilities where Counters can be shared across multiple maps on the same server. This provides a way of having maps interact with each other (and therefore the team members playing their respective roles on such maps). We wrote about this before.

The difference now with Dynamic Scoped Objects is that we can control how often these objects are updated. So, if one team has not changed the Node, they will still see how such a Counter is altered if a competing team does something to change the same Counter.

Again, this will be easier to illustrate with some example cases and scenarios when we have this running in the near future. Feel free to ask questions about this or to make suggestions on cool ways in which to use such shared Counters.

 

OLab4 development resumes

After a pause of several months, we are delighted that development of OLab4 has resumed. We now having funding from a few sources, enough to make a sustained push to get things pushed out the door… and soon.

While we were paused, we took the opportunity to examine where we had gotten to in the development roadmap. It had become clear that sticking with the Entrada framework had too many limitations.

It had also become clear that remaining with the PHP and Javascript base was now too limiting. It had been chosen because that was the most common way to develop a browser-based application in the academic world. But things have moved on and Microsoft’s .Net environment now has so much more to offer.

Since OpenLabyrinth was originally written in Microsoft ASP, it kinda seemed like going back to old ground… and old problems. But .Net is now fully open-source and works across a variety of operating systems. Academic computing is now largely cloud-based, as is so much application software. Using .Net allows us to be either server-based or cloud-based, and affords a whole new degree of scalability if we need it in the future.

Our team has been exploring the difficulties of migrating our codebase across to .Net — it has been great to find that these difficulties are way less than expected. It has also made further development more flexible and has opened up a bunch of new options for us, which I will write about shortly.

There is a big enough change to the functionality of this new codebase that we are releasing it as version 4.5 … and when will this happen?? Soon, young Padewan, soon.