This reminds me of UserLands "Frontier", a Mac product from the early 90s. It was a scripting language and object database. Current execution state and scripts themselves lived in the database.
In 91 or so it was taking advantage of the macs flat address space to do rpc between itself and apps (I wrote a module that let you receive events from the finder).
Around 94, Dave (Winer, the author) was using to handle cgi scripts in "usertalk" its native language, from WebStar, a Mac web server. People would set up web based workflow to (then Mac only) apps like FileMaker and debabelizer.
A few years after that, Dave realized he could be the server himself, and created an app that was basically a webserver living on localhost and let you edit locally and publish your weblogs to a static host.
So, not the same because it's not flat files, but with similar possibilities.
(And a call out to Macintosh Programmers Workshop, which was UNIX like, but allowed selections within arbitrary files be treated as first class files - you could execute a command to take select portion of window 1, pass it to the compiler a land redirect error messages to a section of which now 2. Many a build system came to life this way... Sorry nostalgia...)
So first off, it's always cool to have built and released something, so congrats on that, but these are the questions I'm left with as a potential user:
1. What's different about this setup? What can I do that I either can't with a standard webserver setup or would be more cumbersome that way?
2. Why "files within files", what's different about that compared to directories and index files?What can I do that I either can't with a standard directory structure or would be more cumbersome that way?
If I wanted plain text at the moment + scripts, any standard webserver + CGI would give me that right now and I could host it immediately on a large number of hosts (or on my own). So for people like me who would go "ooh, plain text and unix sounds nice" it'd be good to see a set of reasons why what we'd currently do would be improved using this.
I'll try my best to answer you.
1. I believe you can do it with a standard webserver setup. But when you want to share scripts and files to other users I believe it would just become a bit more cumbersome.
2. For me files within files is a lot more easier. It is not possible to add comments to directories. When you create a directory its just a string. It is not easy to add extra information to the directory itself. I may be wrong.
Again a webserver+CGI would definitely work no doubt. The app just simplifies it for you. Its the same thing with content management system. Its simpler to use them rather than build it manually. Also I plan to add the ability to share files.
I like it. Very much in the spirit of nvALT [1], TaskPaper [2] and to some extent quiver [3].
I prefer human readable formats since it avoids lock in and allows me to edit my content on any platform. The downside of course is lack of media support. Quiver is doing some interesting stuff in that area, but at the cost of losing some human readability.
I too prefer the human consumable format. If by 'media support' you mean embedding media, you can easily script image rendering for it (assuming you compiled with Xlibs or Cocoa support or whatever your platform uses- sadly the best cross-platform interface (QT) is LGPL which will never be upstreamed to GNU/Emacs) and on ELPA there's an extension for basically every audio player out there. I'm not sure what it's like on OS X, but writing a minor-mode to auto-parse file:///home/foo/bar/.avi|.mp4|*.mkv and generate a thumbnail and/or make a clickable URI should be trivial as well.
https://www.madoko.net/ I've been using this for ages, it's a superset of Markdown, pretty solid. It's really hard to beat (La|Te|Lua)TeX for certain things (I'd never write a dissertation or master's thesis on Word because even with all of the plug-ins it's absolutely abysmal for citation management (BibTex) and rendering even the most trivial of diff eqs) but this gives TeX a run for its money. It's a pretty decent option which seems like it might be up your alley. (Org-mode is probably what you're looking for though).
Another here as well...I was excited up until I saw it wasn't self hosted, I had wrongly assumed it was aimed at running a personal/internal web server/site.
I dont get it ... Is it a storage driver, web app, file manager? What makes this better then say notepad or vim? Or saving text files on your local system!?
The reason I created this is that I use plain text most of the time. It was great when using my laptop. With Emacs and shell scripts I could do a lot of things. Keep track of issues, my finances and all. But it was so difficult to keep it online. When I want to access it from my mobile it was not possible. Yes there are several platforms which allow you to store files. But none which allow you to script on them. Its like bringing the shell scripting and plain files of UNIX to the web. Its up to you how you use it. You could store book marks, list issues, take notes. What I think is interesting is the scripting part especially that you can execute a script by making a POST request. This allows you app to react on statuses from other apps.
How about storing plain text files on a cloud server with Syncthing? https://syncthing.net/ (I'm not affiliated with them.) I think it works on mobile and looks like it exposes a rest api too.
So you can have local scripts that affect the files and the changes will be synced for your other devices to see.
I use google keep for online plain text type things. I can definitely see the power of being able to run scripts over these kinds of notes.
For years I had been using a system which was built around yahoo pipes and cron tasks. Pipes would suck in rss sources from a huge number of places, do some munging and logic and output another rss feed which I would process with a cron task to do various things based on what was in the feed.
Have you tried lambda + s3 instead of yahoo pipes + cron? (both time and http activation is possible) I've done something on lambda recently I'd use pipes for (if it still existed) and been quite happy with the result.
I sort of wanted to find a use-case for Pipes and IFTTT, but I couldn't. I think I used it a few times to hunt for craigslist deals on vintage guitar amplifiers or something, but what specifically functionality do you (and OP) miss about it?
The most complex thing I used pipes for was to pull in content from basically every site around the web that I have an account on and aggregate them on a blog of sorts.
The whole idea was that sites I use for things come and go. I could jump from service to service, update my pipes setup. If a site died I'd just find a replacement and move on. I always had all my content harvested and stored in my own db.
Examples;
* any youtube video I added to my favorites would be auto embedded on my blog
* posts on blogger, wordpress, etc all pull into the one place
* images fav'd on deviantart
* pages book marked using diigo
* photos saved to whatever photo site I was currently using
Here's a screenshot from a long time ago when I originally set it up (2009):
Author here. If you would like to try out the app and provide feed back there is a test account. email demo@saola.in and password is Areyouserious1. Would love feedback.
The only feedback that jumps out at me is that while most people will have their own systems, it would be cool to have a simple method to export/import scripts or share them that is built into the site itself.
I imagine a few "standard scripts" like your calculator might be useful to show some of the things you could do and might increase a initial user's stickiness.
Hey, awesome idea. Can't wait to try it out. Unfortunately I'm getting a 504 when I try to register. If you could let me know when things are back up and running that would be great.
The most important role of UNIX is to provide a file system. From
the point of view of the user, there are three kinds of files:
ordinary disk files, directories, and special files.
[DRAFT: The UNIX Time-Sharing System]
> "In the spirit of UNIX, every thing is a file."
"Everything is a file" is a Plan 9, not UNIX, adage. `Block devices aren't a file (though they are represented by files). Network devices are not files (again, they have representational forms, but you can't pipe to them, a la Plan 9).
> "Though unlike it, a file can contain other files. "
By definition, a directory is a file. It's the second item in that tuple of 3 outlined by Ritchie.
You essentially have re-invented Plan 9 and to some extent ACME[1]. Sadly, Plan 9 faded into obscurity due to licensing, but it was poised to fill the position Linux has now. Watch that video [the whole thing) and borrow the good ideas. LISPs are homoiconic in that whole text-is-data sense. ACME takes it a further, in that your terminal is a shell, which can invoke programs to manipulate data. The only other environment I've ever worked where everything was as unified consistently was Smalltalk.
Emacs is a close 3rd and that's hard for me to admit, as an emacs fanatic. Though I can (and have been) doing exactly what you're trying to solve for ages within emacs, but that leaves all the vimmers in the dark ;) Ledger for accounting, org-mode for generic notes, a highly customized e-mail client which I integrated to a calendar/contacts/todo, all of which have tags. I can fuzzy-match my notes to the point where if I'm trying to remember a resource (say, a library for redistribution of data amongst a network on soft-failures), I can search by tag, by time (i.e., I remember it was sometime this week; filter; I remember it was a link on medium.com; filter), and various other components.
I see what target demographic you're going for and it's a pretty good idea. Most people need 'information stores'. Evernote was the Web 1.5/2.0 solution, inevitably there'll be a Web 3.0 version, you might be it.
Side bit of trivia: Cox loved ACME so much he ported all of the essentials when he moved over to Google, from the Plan9 FS (FUSE'd, not native, obviously) to ACME itself.
Thanks for bring up Acme and Plan9. Having used Acme as a primary editor for a while I definitely plan to bring some of its features along. I have ported part of plumbing to elisp though very rudimentary. Though I wonder how plumbing could be implemented in the web. It is an interesting thought.
Yeah I know its unfair to pick on a simple demo/example but it would be interesting for the accounting demo to speak a variant of "standard ledger format" as seen at:
Speaking of standards and processing it would be cool to have a FUSE interface such that I could hand edit ledger files or org mode files on the thing, then via a FUSE mount, continue processing or accessing stuff on my desktop or a server.
the password field says minimum 8 characters, I inputted 9, still not letting me signup. looks like you have a couple of bugs to fix in a critical phase of your app (user registration). will not sign up until this is fixed, but by then (in 10 mins) I will forget Soala, like I forget every other marginally useful app out there.
I can register it without any problems. I don't know what browser you are using. I have tested it on Chrome and Firefox and it works fine. You could send an email to support@saola.in and I could create a user for you.
My first choice was Clojure, but eventually went down the JavaScript way. If there are more supporters for a lisp like language I will add support for it in the future.
In 91 or so it was taking advantage of the macs flat address space to do rpc between itself and apps (I wrote a module that let you receive events from the finder).
Around 94, Dave (Winer, the author) was using to handle cgi scripts in "usertalk" its native language, from WebStar, a Mac web server. People would set up web based workflow to (then Mac only) apps like FileMaker and debabelizer.
A few years after that, Dave realized he could be the server himself, and created an app that was basically a webserver living on localhost and let you edit locally and publish your weblogs to a static host.
So, not the same because it's not flat files, but with similar possibilities.
(And a call out to Macintosh Programmers Workshop, which was UNIX like, but allowed selections within arbitrary files be treated as first class files - you could execute a command to take select portion of window 1, pass it to the compiler a land redirect error messages to a section of which now 2. Many a build system came to life this way... Sorry nostalgia...)