Good question I'm thinking. I thought I'd put the responsde here because I think it is the same question many have and they deserve an answer. So to save effort I've included the reply email here. I just haven't said who I'm replying to :-).
You’ve done a good job in getting people to realise how relatively easy it is to get moodle to work from a usb stick or any other portable memory device. Have you checked out U3 technology. It’s the precursor to USB 3.0 while we all still have usb 2.0 drives. Using that you find that Moodle on a stick runs pretty much as well as moodle on your machine. A stick only costs approx £15 so not out of reach for the average person. So great work. We’ve done just the same with our work check out http://docs.moodle.org/en/Development:Offline_Moodle. It’s great that we now have multiple ways of running Moodle on a portable device. That’s got to be good for those who need it. Nice work. I’ve included these references in case there’s any thing you want to take from what we’ve done. I like to share since I always borrow from others. Life seems easier that way J
Anyway the synchronisation work is a good topic and there is a reason we’ve been quiet. It really comes down to it being ‘the’ challenge. As you’ve said packaging up Moodle and running it on a device is a relative cinch. Getting two Moodles talking to each other database to database was relatively easy to do also. Took a month or two but we got it working for forums and simple things like resources. Problem is this is insecure and couldn’t happen in real life. It just proved that if you had a reliable way of getting the data and files from a to b then synchronisation is entirely possible. Proving this for forums was key because it was complex enough for people to feel it wasn’t possible.
So getting data in and out of Moodle and marking it up so you know where it fits, what are changes etc is in my opinion key to being able to sync. That’s where Moodle isn’t sufficiently advanced enough. I haven’t said this so bluntly before because I don’t want to appear negative. Moodle is still young it’s achieved a lot. However the concept of being able to share information reliably between separate instances has a lot of hidden and upfront security, technical and other requirements. These haven’t been addressed from the start and so implementing them now is possible but requires significant effort.
For example for the second prototype I moved from transferring data directly between the databases to using the backup and restore process to package up the data into a file that could be transported and then read in at the other end. Again this works but now we’re using tools that aren’t mature yet. They’re very good tools. Backup is a fine piece of work but it needs a refactor those things that weren’t quite built right initially. The same goes for web services. I used Moodle Network. It’s great but it’s young and wasn’t designed from the outset to work specifically like a web service. As far as I know Moodle still does not have a standardised web service api or a mature web service component. It will have in time I’m sure but not right now.
We chose backup because, at that point, it was the only tool that had access to all parts of Moodle and a defined and supported process for getting data and files in and out of Moodle. It also new where to get everything from and how to put it back reliably. While it’s not perfect it fits the bill and just needs work.
The synchronisation work began with the concept of incremental backups/updates. Basically breaking large files down into smaller ones and ensuring you don’t have to download larger updates. Just what you need at that given time. That went well but we’re trying to do so much here at the OU that the offline work has to compete with other demands. It requires a lot of work and other areas such as mobile tools demand a lot of attention.
I always felt that an Offline solution was a necessity and also very possible. However I also see that it is kind of the last stop on a long journey towards making Moodle ubiquitous in our lives. I think it is a worthy step
but it’s best achieved whilst achieving other goals too. That way the cost is paid as we go along. Each new problem solved proves the work we’re doing. Another way of putting it is that synchronisation is essentially a series of questions and answers. What has changed since I last updated? What changes has a student made? What is a student going to do offline? What content do they need? Moodle is not built to make answering the questions very easy. Each question has to be thought of before it’s asked and specific solutions for each need to be developed and maintained. It would help us if there were a common set of places where we could ask generic questions and get answers. We then combine these answers to provide the full answer that is sought by the user or system. This is quite an abstract notion. I’d like to explain it further but I’m conscious I’ve already rambled on enough.
For those who’ve already fallen asleep all I really said is that Offline Moodle is entirely possible however it’s a long arduous road to achieve it, unless some one can explain a better way. Moodle isn’t built to easily answer the questions that synchronisation asks of it. Adding support for that will likely require fundamental changes Martin D and the community will resist. Therefore political as well as technical challenges lay ahead. We’re in the process of looking where next? The incremental backup stuff has been impacted by other demands. It’s still there but waiting. I prefer to kill many birds with one stone, it’s often cheaper that way, so there’s a possibility we’ll detour and focus on mobile solutions as a way to provide the underlying functionality an offline solution requires.
Whew that’s a lot. However when you ask an important question I prefer to give a (half) decent answer. I hope that goes some way to explaining our position. We’re not stalling. Just planning where to go and until we’re clear there’s not much point in spreading the news.
Kind regards
Colin
edit: 20100203
Just found out about bitnami. They provide pre configured moodles for many situations. Not sure pricing etc but could be useful
You’ve done a good job in getting people to realise how relatively easy it is to get moodle to work from a usb stick or any other portable memory device. Have you checked out U3 technology. It’s the precursor to USB 3.0 while we all still have usb 2.0 drives. Using that you find that Moodle on a stick runs pretty much as well as moodle on your machine. A stick only costs approx £15 so not out of reach for the average person. So great work. We’ve done just the same with our work check out http://docs.moodle.org/en/Development:Offline_Moodle. It’s great that we now have multiple ways of running Moodle on a portable device. That’s got to be good for those who need it. Nice work. I’ve included these references in case there’s any thing you want to take from what we’ve done. I like to share since I always borrow from others. Life seems easier that way J
Anyway the synchronisation work is a good topic and there is a reason we’ve been quiet. It really comes down to it being ‘the’ challenge. As you’ve said packaging up Moodle and running it on a device is a relative cinch. Getting two Moodles talking to each other database to database was relatively easy to do also. Took a month or two but we got it working for forums and simple things like resources. Problem is this is insecure and couldn’t happen in real life. It just proved that if you had a reliable way of getting the data and files from a to b then synchronisation is entirely possible. Proving this for forums was key because it was complex enough for people to feel it wasn’t possible.
So getting data in and out of Moodle and marking it up so you know where it fits, what are changes etc is in my opinion key to being able to sync. That’s where Moodle isn’t sufficiently advanced enough. I haven’t said this so bluntly before because I don’t want to appear negative. Moodle is still young it’s achieved a lot. However the concept of being able to share information reliably between separate instances has a lot of hidden and upfront security, technical and other requirements. These haven’t been addressed from the start and so implementing them now is possible but requires significant effort.
For example for the second prototype I moved from transferring data directly between the databases to using the backup and restore process to package up the data into a file that could be transported and then read in at the other end. Again this works but now we’re using tools that aren’t mature yet. They’re very good tools. Backup is a fine piece of work but it needs a refactor those things that weren’t quite built right initially. The same goes for web services. I used Moodle Network. It’s great but it’s young and wasn’t designed from the outset to work specifically like a web service. As far as I know Moodle still does not have a standardised web service api or a mature web service component. It will have in time I’m sure but not right now.
We chose backup because, at that point, it was the only tool that had access to all parts of Moodle and a defined and supported process for getting data and files in and out of Moodle. It also new where to get everything from and how to put it back reliably. While it’s not perfect it fits the bill and just needs work.
The synchronisation work began with the concept of incremental backups/updates. Basically breaking large files down into smaller ones and ensuring you don’t have to download larger updates. Just what you need at that given time. That went well but we’re trying to do so much here at the OU that the offline work has to compete with other demands. It requires a lot of work and other areas such as mobile tools demand a lot of attention.
I always felt that an Offline solution was a necessity and also very possible. However I also see that it is kind of the last stop on a long journey towards making Moodle ubiquitous in our lives. I think it is a worthy step
but it’s best achieved whilst achieving other goals too. That way the cost is paid as we go along. Each new problem solved proves the work we’re doing. Another way of putting it is that synchronisation is essentially a series of questions and answers. What has changed since I last updated? What changes has a student made? What is a student going to do offline? What content do they need? Moodle is not built to make answering the questions very easy. Each question has to be thought of before it’s asked and specific solutions for each need to be developed and maintained. It would help us if there were a common set of places where we could ask generic questions and get answers. We then combine these answers to provide the full answer that is sought by the user or system. This is quite an abstract notion. I’d like to explain it further but I’m conscious I’ve already rambled on enough.
For those who’ve already fallen asleep all I really said is that Offline Moodle is entirely possible however it’s a long arduous road to achieve it, unless some one can explain a better way. Moodle isn’t built to easily answer the questions that synchronisation asks of it. Adding support for that will likely require fundamental changes Martin D and the community will resist. Therefore political as well as technical challenges lay ahead. We’re in the process of looking where next? The incremental backup stuff has been impacted by other demands. It’s still there but waiting. I prefer to kill many birds with one stone, it’s often cheaper that way, so there’s a possibility we’ll detour and focus on mobile solutions as a way to provide the underlying functionality an offline solution requires.
Whew that’s a lot. However when you ask an important question I prefer to give a (half) decent answer. I hope that goes some way to explaining our position. We’re not stalling. Just planning where to go and until we’re clear there’s not much point in spreading the news.
Kind regards
Colin
edit: 20100203
Just found out about bitnami. They provide pre configured moodles for many situations. Not sure pricing etc but could be useful