[discussion] RaspberryPi mode

[wesvetter]

Lack of internet access in target countries has been a challenge for us for a while. One possible solution is running a creating a local network, django server on a RaspberryPi and then syncing changes to the WHWN if and when internet become available. In this case, WHWN would be acting more like a backup then an exchange platform. But we could still provide local inventory management and communication solutions. The use case I think this would be good for is a clinic where electricity is available but internet is not. Inventory could be catalogued with low-cost tablets like the Aakash tablet.

The KALite team has already done quite a bit of work in this area, so we might not have to reinvent the wheel.

Potential areas of concern (that I can think of, there are likely more):

• user interface will need to reevaluated, since we didn't design for a tablet/phone
• syncing data will be a challenge
• range of the network

[lewisf]

• I agree, user interface should be reevaluated.
• looks like we should be looking for an asynchronous multi-master replication solution. I've found SymmetricDS
• this adapter says it has up to 3x range of 802.11g. This means we can probably expect at a minimum 45m indoors, 91m outdoors, and a maximum of 135m indoors, 270m outdoors. Of course we should test this ourselves before guaranteeing such claims.

[wesvetter]

If we decide on tablets as an interface, then we may want to look at a responsive grid system, which it doesn't look like 960 supports. unsemantic appears to be the successor to 960, but if we have to switch to something else we can also look at whatever else is the flavor du jour for responsive stuff.

[chushao]

Why would we need a raspberry pi? Assuming they're running android, can't we just provide auto scripts that create a web app on the tablet itself? ie https://play.google.com/store/apps/details?id=com.galoula.LinuxInstall http://keniallee.blogspot.com/2012/08/django-14-for-android-only-dev-runserver.html

Or, if stability is needed, create an android app (in java shutters) and then just rip open some RESTful API calls on our site. Let everything do itself locally and then sync it as backup directly to whwn?

It might be less work on our side to have a medium of rbpi but I really don't see the point of having that as a cost.

This is all assuming we're using tablets as an interface.

[lewisf]

i don't know. that sounds like it'd be more of a pivot than what we currently have, and I'm not sure how easy it would be to explain to our users how to use a system like this. It has to be super simple, and I can't think why something like:

1. Connect rbpi to outlet
2. Connect multiple onsite tablets to LAN network broadcast by the rbpi
3. Browse to http://someurl/
4. Use service
5. Connect rbpi to WAN at home base to sync with cloud

isn't the most obvious solution at this moment.

maybe im misunderstanding what you're suggesting @chushao

[chushao]

Oh I was suggesting skipping out the rpi in general.

Two ways (assuming android tablet):

1. install python/django on tablet.
2. run webserver (actually a local client) on localhost
3. connect to wifi to sync with whwn.

Native:

1. Write basic inventory management tools for Android using SDK.
2. Create some RESTFUL api that the android app will sync to when you get online.
3. It saves data locally but then when it connects to wifi it will synchronous the web server data with itself and vice versa.

[lewisf]

The main issue I see with what chu is proposing is having too many devices needing to sync back to one master. We're going to have to deal with a crap ton of conflict resolution, which is fine, just we're going to have to do it.

What I was thinking with the rbpi model is to have all tablets modifying a single database synchronously. Benefits here is everyone on site sees the same data and when syncing back to cloud, there shouldn't be as much conflicts to resolve? I think.

Ho

[lewisf]

I think though a large reason why Chu and I are disagreeing is because we are imagining different use cases.

[wesvetter]

Lewis is probably right about the use case thing. Chu, what are you envisioning?

I'm assuming they have electricity but no internet except intermittently. I would assume they don't have a LAN either. In that case, the rPi is convenient because it also provides the LAN.

If we did a native app, how would the apps sync without a LAN? Can they generate one?

There's quite a few assumptions there; @jnwng can you email Dr. Frederick about doing another phone/skype call?

[chushao]

Ah, if they don't have a lan that would be a problem.

I was thinking of having apps sync with each other ad-hoc tablet to tablet, and then if there's a router anywhere that can actually connect online, any of the tablets can sync with online as well. I'm just thinking that the rpi in the middle seems to be pointless.

[lewisf]

how well does adhoc on tablets work? how obvious is it to get it working? i remember there being issues with it a year or two ago.

also, although having multiple tablets would mean there's multiple failsafe options - at the top of my head, i feel like implementing this would take a lot more work (we'd have to handle a lot more inconsistency) than running our app as it stands on a raspberry pi with the necessary modifications to get people to access it at a url - or within an app that has a web container.

[wesvetter]

In terms of what we can ship fastest, I think going the route of an rPi is the easiest since synchronization is the simplest in that situation. But this is all assuming a certain use-case.

[jnwng]

i want to make sure this is actually useful before putting too many resources into this. we still haven't confirmed that the overhead of getting all this organized is going to be much easier than just writing things down on paper