Review my startup: Akshell, a web application network
akshell.com
akshell.com
Check out the mailing list as well, if you're not on it already: http://groups.google.com/group/commonjs
I'm also thinking of it as a community-based implementation of something like Yahoo YQL, so mashing together several useful datasources and using JavaScript as the glue.
A directory of apps written with Akshell would be more powerful than a screencast or explanation. If you don't have very many users yet, write the applications yourself.
It might be wise to hire or find someone to narrate the screencast.
Great work!
Yes, currently I am working on creating new apps. Sorry for my accent, I'll fix the screencast.
Appjet had the same concept: server side js based on rhino, persistent js object store, etc.The concept, however, was a little bit rudimentary: one app consisted of one js "file". You had to write every possible interaction as functions within that file. It did have an interesting function call based templating mechanism, however, something like so:
print(DIV(
FORM({action:"/", method:"get"},
SPAN({style: "float: left;"}, "Show"),
INPUT( {name: "count", value: count, size: "2", className: "in_box"} ),
SPAN({style: "float: left;"}, "items"),
INPUT( {value: "Go", className: "in_box", size: "1", type: "submit"} ),
DIV({style: "clear: both;"})
)
));
Currently I don't have plans to opensource the engine. It isn't a noncommercial project; I spent a lot of time on it. What business model would you suggest if I opensource the engine?
In fact, it's impossible to port Akshell database to App Engine. The database system is my pride: Akshell provides a special query language for it, which is based on relational calculus and easily integrates into JavaScript. A relational database couldn't be ported to Big Table.
Akshell features another approach to scalability: each application has an access to a fully functional relational database with transactions, complex queries, etc. Application databases are completely independent; so the whole system has a non-relational database, which should scale well if multiple applications are loaded. You may imagine it as "relativity islands".
The database API is described here: http://www.akshell.com/docs/ref/core/db/
1. business lock-in: Having one's whole web business(code/website&data) be hosted by a small startup out of russia(ssor) will be a non-starter for most. 2. code lock-in: Having "code lock-in" for developers, meaning writing to a proprietary code-stack for an ssor will also be a non-starter. 3. scaleability: akshell does not currently provide a clear path to scaleability for any one app let alone the potential of hosting 1000's of apps. This very rapidly becomes a cloud-scaling issue that the ec2, gae's are attempting to solve and will be a non-starter for an ssor . 4. dynamic code sharing - use'ing other libraries within askell might reduce development time, but unless there is a static version of that library associated with each instance, with any change the possibility of breaking the web services makes this a non-starter and everyone would revert to a github like "static code sharing" model.
Here are the pros
1. A custom webhook pipe builder: Say I wanted to build a "dynamic form" get user input, save state (in a db) and run it through a series of dynamically created "webhooks" and process the final output. If akshell provided "an app development api" I could dynamically create an app, generate the code have it hosted and throw the url up for user input and have the user walk-thru various webhook/needed steps to process & generate a final response. - this is not now possible w/ appengine or ec2 - propietary code/data lock-in is a non-issue since I am not "storing" as much as I am processing. - leveraging "dynamic community code" would be a pro/ not a con in this case. - a freemium model would be possible as i'd need free to wade in/ test etc and with load expect to pay a per use fee. - see some of Jeff Lindsay's webhook related work i.e. webhooks, mailhooks, scriptlets.org etc at http://github.com/progrium for related work
2. A mashup test/use-bed: Web sites with apis could create "canned akshell apps" that not only allowed developers to use("foo-api") to test but also provided examples of use and each web-service could possibly subsidise the hosting / bandwith costs of using their api-apps so developers could just plug-n-play.
3. There are a few more use cases i can think of, you could shoot me an email if interested.
I'll contact you. Thanks again for feedback.
This is quite impressive, I enjoy the availability and ease of entry of the javascript language. Everyone with a browser has access to it.
I signed up Anton :D (does it work with jQuery)
You can use any client-side JavaScript library with Akshell, including jQuery.
Making it easy to move away lowers the potential cost of using Akshell - I really don't want to be locked in. How about open sourcing whatever is needed to run an app on your own server and then working on keeping customers through convenience and the interoperability between apps?
And when I suggest open sourcing I am thinking in terms of the bare minimum to setup an app on another server - so your very cool editing system wouldn't need to be part of it, that would be what makes you different from anyone else who sets up their own server.
The former requires that I trust you completely and permanently and is therefore not likely to happen in serious contexts. The latter requires a round-trip through my VCS anyway, so what benefit does this feature bring over e.g. Github?
The resulting environment is easy for development, is formed by a community, and is stable.
Other developers could gain an authority and authour such applications as well. In future, they will be able to make money on it.
The cloning is a good way for libraries, but in Akshell you could create utilities as well. It's easy to explain by an example: in the profile application users save their profiles; other applications could access them. Cloning the profile code is senseless, because its data matter.
You can use it like this:
sudo easy_install akshell
akshell get your-app
# make changes
akshell put your-app -e "test()" # send changes and run the test() function
It can be integrated into an IDE (I use it from Emacs). But it isn't a substitution for a version control, which wouldn't be handy here because of short put cycles.
Why not provide a login system specific to each app?
Maybe get someone else to voice-over the intro video.
Yes, I'll fix the video.
Unfortunately the project seems to be shelved now.
1. The deployment is just two clicks.
2. Applications can interact, i.e., your app can use the log app for logging, the profile app for accessing user profiles, etc. So each app does only one thing, but does it well. It can be imagined as a social network, whose logic and content is formed entirely by users.
For instance, can anyone link their app with mine? How do we keep everything consistent?
use('log', '0.1');
...
log.debug('Your log message');
The first line includes the file http://www.akshell.com/apps/log/code/0.1/__init__.js which is an interface of log. Then you can view your logs at http://log.akshell.com/
The admin of log maintains consistency of the interface; so other developers can use it.
Anybody can use your app if he trusts you. If you don't maintain consistency of your utility interface, nobody will use it.
It is not like friending. The friending itself can be implemented as an application.