Extensible Loader


Would you like me to kick that off?
What’s the stack? PHP+MySQL? NodeJS? … Tomcat? :fearful: shudders


Main server is Apache+mysql (wordpress), discourse forums is on nodejs


This weekend was a bit crazy and I didn’t have time to code anything. -_-

I’m under the impression that the more straight-forward way to make an upload system is to make a set of simple webservices in php backed by mysql. Maybe it would use wp-discourse to know who is logged in? When logged in, it would allow users to manage (upload, update, edit, delete) their own games. If not logged in, you can still browse/search/download public games. The interface itself would be in javascript and would make queries to php using JSON. File downloads could be served by PHP so we can track how many times a file was accessed.

Does this sound OK?


You mean client-side JS? I’m not a big fan of sites that require JS to function unless necessary and I know a few people who straight refuse to turn on JS in their browsers. Could there at least be some fallback non-JS version?


But looking at this forum right now it seems like it’s already dependent on JS a lot – if I turn it off, it’s basically a not-so-nice read-only something :smile: In this case I guess this won’t hurt any more. But it would be nice if at least browsing and downloading games remains possible.


It can be done, but it’s just more work for a slower/kludgier experience. :confused:

I structured it this way so that, with networking on the Pokitto, we’d be able to browse and download games on it directly.


Do you know if it would be possible to do all that from a cell phone? Like plug in my pokitto to my phone and transfer?


I think so. If @jonne’s PPPDemo works with a phone, it’d be a good indicator.


I don’t blame them.
There’s a lot of websites who use JavaScript for frivolous things that just waste CPU time, like animated adverts or random timers, not to mention tracking people’s browsing habits.

I don’t go quite that far, but I use a whitelist approach for cookies and only accept cookies from sites where I want to log in.

Either way, I like a nice REST API so people can build their own clients.
(And of course, that lets the command-line addicts curl their uploads.)


That’s done all server-side, AFAIK, no javascript needed… and the worst cases are precisely the sites where you have to log in to use them.


Not all. Device fingerprinting typically requires JavaScript.
Of course that’s not the only tracking technique available, there’s also canvas fingerprinting, which is one of the reasons I don’t let my browser use my GPU.

That’s why I’m selective about what sites I sign up to and use certain browser extensions.

(I accept that I can’t combat everything, even if I went fully hard-core with it all, but if I’m at least making it a bit more difficult than the average user that’s good enough for me.)

This is a good point too.
If we ever get that wifi hat, cutting out JavaScript would make life easier in some respects.


Let’s not get too offtopic but the people I’m talking about either have issues with proprietary JavaScript, bloat, performance demands, support in browsers (some use TUI command line browsers), privacy concerns (JS can detect things servers can’t and use them to track you even without cookies) or think that executable code in HTML documents is a bad idea in general.

I’m personally already dreaming about a simple web browser on Pokitto, which would probably not support JS either, so it wouldn’t be able to view its own site :frowning: But if it saves a lot of effort and fits the current framework, I say go for it.


This website actually works without JS (but no login). Here it is in links on my shiny 4:3 Puppy Linux:


That’s true… though, because of the limitations (useragent spoofing, iOS devices all having the same fingerprint, or the fact that people use the internet on a range of devices all the time now) it’s so much more effective to just require users to log in. I suspect that fingerprinting is more of a theoretical threat than a real one.

Parsing and rendering HTML is probably too much for the Pokitto already… which is why I suggested that PHP should respond to queries in JSON (much more compact, trivial to parse).
Turning that JSON into something user-friendly would be done client-side. On the Pokitto, you’d have an “app store”. On the PC, a browser running javascript is the method with the best experience and least friction for the end user… though it can be made to “degrade gracefully”, time permitting. I’ve got way too many simultaneous projects going on. :laughing:

My personal stance on javascript/privacy is that disabling javascript to protect one’s privacy is like throwing the baby out with a scoop of bathwater. Your freedoms are still being violated server-side, in ways that are far worse. The problem isn’t javascript, it’s the web’s dependency on advertising to fund itself.


I’m not such a privacy freak… I think it’s important for others though… I just see plain HTML as KISS and more fun, JS + complex CSS ruin the fun of being able to view websites on a toaster etc. :smile:


For desktop and laptop users it’s still an issue though.
(I don’t use the internet on my ancient phone, so the ‘range of devices’ thing doesn’t affect me.)

I don’t know how good they are, but there are libraries on GitHub for doing browser fingerprinting, so I’m classing it as plausible.

This is true, but I think part of the solution is more filters on what data a server can request from a browser.
I.e. one should be able to configure a browser to refuse to send geolocation data, information about the OS etc

Part of that problem is that there are a lot of JavaScript APIs that allow access to that information.
(Certainly not the whole problem, but a problem nonetheless.)

(I’d like to point out that although I use open source licences a lot, I don’t follow the same school of thought as Stallman.)

(Unrelated: it annoys me when people start using ‘her’ or ‘him’ to refer to a hypothetical person. A hypothetical person should be ‘they’ or ‘one’.)

Don’t we all? :P

I’d agree with that too.

I don’t mind unobtrusive static images, but anything animated or worse I detest, regardless of the product.
(Most of the time adverts have the opposite effect on me anyway - I end up wanting to use the product less because they have an annoying advert.)

I’m still not a fan of JavaScript though.
There are cases where it’s useful (for example, this box I’m typing in for posting comments) but there are lots of other cases where I think it’s overused, used frivolously or just eats too much RAM.

I partly agree with this. I don’t mind CSS so much, but I prefer static websites where possible.

When it comes to websites, I think relatively simple layouts like Wikipedia and cppreference are much nicer than a lot of modern websites.

That said, I also hate the modern ‘minimalist’ approach where the main page is just a bunch of tiled slogans and advertising the product without actually giving you much detail about what the product really does.

For example, the slack website - loads of marketing speak and doodles, nothing showing me what it actually looks like or explaining how to use it.

Wikipedia is essentially what HTML was built for - hypertext was designed to be used for encyclopedia-like systems, like ENQUIRE.

I used to have a copy of Lynx. Great fun.
Maybe we should have stuck to using Gopher? :P


You’re not alone who’s fed up with it – fun link (and since we’re a family friendly forum, let me warn you it contains a few swear words).


I couldn’t agree more.
It reminds me of this:


Alright, I can’t resist replying once more. This is the fastest website in the world (watch out, horrible sound):


it fits into a single TCP packet (source).


Obligatory headphone and party parrot warning. :scream_cat:


It is too late @FManga

I have seen everything


(This should come with an epilepsy warning.)


A couple of things that would be good to have in the loader eventually.

  • The game specific loading screen support. Every person who has lived with the 8-bit computers knows what that is :wink: Even if the loading do not take minutes or tens of minutes like in the 80ies, it would be nicer to stare at the nice loading screen graphics instead of the “Loading…” text or just a progress bar.
  • After loading/flashing & restart, there is no need to show the Pokitto startup screens. Just start the game as soon as possible. When the device is restarting the next time, normal startup screens can be shown. That can be handled by storing the startup state to the eeprom.