tasiaiso/tildefriends
1
0
Fork 0
forked from cory/tildefriends
Code Issues Pull Requests Releases Wiki Activity

Remove some cruft. Fix a first run issue.

Browse Source 
git-svn-id: https://www.unprompted.com/svn/projects/tildefriends/trunk@3628 ed5197a5-7fde-0310-b194-c3ffbd925b24
This commit is contained in:
Cory McWilliams 2021-01-03 20:25:52 +00:00
parent f63242cad1
commit 9cf1d38611
3 changed files with 4 additions and 128 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
core/core.js
View File

@ -312,7 +312,10 @@ function setGlobalSettings(settings) {
} }
try { try {
gGlobalSettings = JSON.parse(readFileUtf8(kGlobalSettingsFile)); var data = readFileUtf8(kGlobalSettingsFile);
if (data) {
gGlobalSettings = JSON.parse(data);
}
} catch (error) { } catch (error) {
print("Error loading settings from " + kGlobalSettingsFile + ": " + error); print("Error loading settings from " + kGlobalSettingsFile + ": " + error);
} }

62
data/wiki/development
View File

@ -1,62 +0,0 @@
= SandboxOS App Development Guide =
This is a brief introduction on developing SandboxOS apps targeted at people who are already familiar with web development.
== Packages ==
A package is a directory of files. '''package.json''' is the only file with special meaning.
Here is an example package.json:
{{{
#!json
{
"name": "chat",
"start": "backend.js",
"imports": ["auth", "httpd", "filesystem"],
"href": "/chat",
"description": "A basic multi-user chat example."
}
}}}
* '''name''': identifies the package. If it is not unique, any existing installed package of the same name will be replaced when installing the package.
* '''start''': specifies the JavaScript file which is the entry point of the task. When a new process is started for this package, this script is executed within it.
* '''imports''': list of package/task names which this package wants to be able to access.
* '''href''': link to the task's entry page used by [/tasks /tasks].
* '''description''': human-readable description of the package, displayed by [/tasks /tasks].
== Promises ==
JavaScript promises are used heavily. Invoking any method on another task will return a Promise object. Execution will return immediately but go asynchronous. That usually looks like this:
{{{
#!javascript
imports.email.sendMessage(message).then(function(result) {
// When sendMessage completes, result is the return value.
}).catch(function(error) {
// If sendMessage fails (or calling it somehow fails), error is the reason.
});
// sendMessage returns immediately and execution continues on.
}}}
This is a completely inadequate explanation of the nuances involved, but it's a starting point. Promises can be created and chained and combined in interesting ways.
== Inter-Task Communication ==
Tasks have access to the exported functions on any task declared in their package imports.
In addition, functions passed between tasks can be called by the receiving task or passed along further.
Here is an untested, made-up example with two hypothetical tasks, '''math''' and '''test''':
'''math.js''':
{{{
#!javascript
exports = {
sum: function(a, b) { return a + b; },
multiply: function(a, b) { return a * b; },
};
}}}
'''test.js''':
{{{
#!javascript
imports.math.sum(4, 5).then(function(result) {
// result === 9
});
}}}

65
data/wiki/index
View File

@ -1,65 +0,0 @@
= SandboxOS =
I embedded a JavaScript engine in a C++ application and used it to make some webapps. I made a wiki with it. That is what you are looking at. It's not especially good, but the interesting part is that you, as a visitor to this web site, have the power to rewrite the wiki webapp itself into something better.
== Goals ==
I've tried writing lofty descriptions about why I think this is cool, but I'm bad at that part.
Goals include:
=== 1. Make it easy to run servers. ===
* SandboxOS can be made to run on lots of platforms.
* SandboxOS can be made trivial to install. I want to put it in app stores.
* SandboxOS is an app store in itself, so think "installing blogging software == installing a mobile game". And then think of a webapp that is 10x better than that.
=== 2. Make a thing that is by default pretty secure. ===
* Actual access to most system resources (filesystem + network, currently) is restricted to a few apps that hand it out in very limited ways.
* Apps will only get access to resources when granted by the user. Think iOS or Android.
* The idea is that it can be made as secure as Google Chrome. It currently uses V8 and process isolation, but there's a lot more to do. In the end I want to trust installing random apps as much as or more than I trust visiting shady web sites.
* But security is nothing if you can't do cool stuff. I want to make weird social music players and things to manipulate photos on my phone from my desktop.
=== 3. Free software idealism ===
* This is Wikipedia but for apps?
* Make distributed versions of things that Google/Apple/Facebook dominate?
* Something about software architecture and making small tools that fit together to do neat things.
=== 4. Fun ===
* I get a kick out of making all of this stuff from scratch. The stack is getting pretty high, and it's just getting started.
* This hopefully lowers the barrier to entry to making little webapps, since you can use my server and make something with ~2 files that you edited like something on Google Docs.
== How to Get Started ==
{{{
#!html
<ol>
<li>Visit the <a href="/tasks">/tasks</a> page.</li>
<li>Pick a task (hint: consider <b>helloworld</b>, <b>wiki</b>, or <b>chat</b>). Click edit. You will probably have to log in at this point.</li>
<li>Make modifications.</li>
<li>Click install.</li>
<li>Visit your updated task's URL and see it updated.</li>
<li>Ask questions. Either stick them here on the wiki somewhere, or email <a href="mailto:sandbox@unprompted.com">Cory</a>.</li>
</ol>
}}}
It should be difficult to do anything too disruptive, and there are backups if you do. '''Don't worry about breaking things.'''
It's easy to make things fail silently. I'm starting to improve that. '''Use the log task.'''
There are probably ways to do bad things if you try hard. '''Please don't be mean.'''
== TODO ==
In no particular order:
* Set limits for everything. n anonymous users can each make m tasks with p MB of storage and can make q HTTP request per second.
* Make some sort of TODO / bug tracker to replace this task list.
* Establish some conventions for non-webapp tasks. Maybe make a shell that lets you run code from any task that exposes it.
* Establish some conventions for HTML fragments. Include a persistent HTML header in every page or something like that.
* Make an app store. Not too important until we have multiple installs but pretty important.
* Lots of the API exposed from C++ isn't async but should be.
* Pick a name for this thing.
* ~~Set up an [https://www.unprompted.com/projects/build/sandboxos automated build].~~
* Feedback is really bad or missing. If you break a task, it might just stop responding to web requests. I have the benefit of being able to see console output, but that's really noisy and bad. There might be times where it is necessary to restart the whole process. Ultimately there should be a way to see feedback when you've broken something, and things should be hardened so that you can't take down the whole system without abusing administrative rights.
* Security here is not good at the moment. I'm essentially trusting you to please don't do bad things. I've taken some steps to harden this thing, but it has a long way to go.
* ~~Inter-task messaging is really awkward to type. And the way you need to respond to httpd requests is even weirder. I will work on this. It should be possible to get most things close to being first-class function calls, except asynchronous.~~
* ~~Make this wiki actually use some sort of wiki syntax. HTML is too 90s.~~
* ~~The C++ program needs to use separate processes for each task in order to prevent OOM situations in one task from taking down the whole process.~~
* ~~The C++ program needs to build and run on Windows.~~ It needs to do so as transparently in the background as possible while still being trivial to acquire and start (Windows service / system tray icon).
* ~~Need to implement a real security model. I was thinking once this has an authentication task, everything can use that to enforce that nobody but administrators changed the core tasks and that anonymous and untrusted users don't do anything too malicious.~~
* ~~Be able to marshal functions across task boundaries so that the httpd task can return a request object that has the same API as node.js. I think this will greatly simplify the client code for webapps.~~
* ~~Need to implement something like proper javascript requires() and package dependencies for code sharing.~~