[ssriram]

This is quite innovative, a javascript appengine if you will. I am not so keen on the enforced sharing, I think separating "library modules" from "user apps" and providing opensource access to the "akshell" engine so folks could host their own, port the db over to google appengine etc. would make this rock. So, is the akshell engine's source open/available now/later??

[korenyushkin]

Thank you for your appreciation!

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/

[ssriram]

Here are the cons

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.

[korenyushkin]

Thank you for your comprehensive reply. I definitely agree that now Akshell doesn't suite mission-critical applications. And I think it will never suite bank applications or such. But I think that it has a rather big niche.

I'll contact you. Thanks again for feedback.