![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
izardIt's been one and a half years since I first decided I will implement a personal cloud solution. Six months ago, I realized how to make it secure for a service provider side. That was the biggest technical issue I needed to resolve to make it fly.
It was always difficult to find time to work on it, because there are always important work related projects that obviously had a priority. So I cheated: I've registered this project as a demo for an internal conference. This gave me an opportunity to use company's h/w to work on it, but 90% of the coding I had to do in my free time any way. However, a clear deadline (this Monday) helped a lot in motivating me. I managed to finish coding of a prototype which I can show to wider audience few days before the show :)
The demo was a success: it was selected as 3rd out of 40 projects. It was the only one out of top 20 that was done by single person as an unofficial project. Now thanks to feedback I got on this conference in Portland (I am writing this from PDX on the way home now) I have a clear picture about technical and marketing opportunities for AdHoC.
It is skunksworks project which is not really related to my job so I think it's safe to post about it before I get a formal approval to make it open source. (If I don't have the approval and someone will do something similar and open source I'll be happy too.)
AdHoC is an service to enhance user experience on Small Form Factor(SFF) devices. It allows _secure_ remote execution of any application on a "close" x86 box, redirecting a screen and input to SFF device.
I call it cloud because it can satisfy 4 out of 5 clauses of formal NIST cloud definition. It is PaaS variation.
Here is a technical description for those who might be interested:
On the client side (SFF device) user needs only a VNC client and http browser installed. On the service provider side, an AdHoC server package I’ve developed has to be installed. It consists of several CGI scripts, linked with a library providing Remote Frame Buffer service, and Google Native Client secure container. The application has to be recompiled to be used as AdHoC service using Google Native Client toolchain. Currently only Linux applications are supported. I will work on supporting full QT Meego apps and eventually Windows apps.
For end users, it enables running many classes of CPU demanding application on SFF device.
For ISVs, it adds an additional usage model/market for their existing applications that are currently too CPU consuming to be ran on SFF devices.
For Telco/ISP/Wifi access point’s owner it adds another service to sell/provide besides internet access using existing billing infrastructure.
I will try to keep it as simple as possible, and to continue using existing open source components and protocols (HTTP, RFB, Google Native Client).
It was always difficult to find time to work on it, because there are always important work related projects that obviously had a priority. So I cheated: I've registered this project as a demo for an internal conference. This gave me an opportunity to use company's h/w to work on it, but 90% of the coding I had to do in my free time any way. However, a clear deadline (this Monday) helped a lot in motivating me. I managed to finish coding of a prototype which I can show to wider audience few days before the show :)
The demo was a success: it was selected as 3rd out of 40 projects. It was the only one out of top 20 that was done by single person as an unofficial project. Now thanks to feedback I got on this conference in Portland (I am writing this from PDX on the way home now) I have a clear picture about technical and marketing opportunities for AdHoC.
It is skunksworks project which is not really related to my job so I think it's safe to post about it before I get a formal approval to make it open source. (If I don't have the approval and someone will do something similar and open source I'll be happy too.)
AdHoC is an service to enhance user experience on Small Form Factor(SFF) devices. It allows _secure_ remote execution of any application on a "close" x86 box, redirecting a screen and input to SFF device.
I call it cloud because it can satisfy 4 out of 5 clauses of formal NIST cloud definition. It is PaaS variation.
Here is a technical description for those who might be interested:
On the client side (SFF device) user needs only a VNC client and http browser installed. On the service provider side, an AdHoC server package I’ve developed has to be installed. It consists of several CGI scripts, linked with a library providing Remote Frame Buffer service, and Google Native Client secure container. The application has to be recompiled to be used as AdHoC service using Google Native Client toolchain. Currently only Linux applications are supported. I will work on supporting full QT Meego apps and eventually Windows apps.
For end users, it enables running many classes of CPU demanding application on SFF device.
For ISVs, it adds an additional usage model/market for their existing applications that are currently too CPU consuming to be ran on SFF devices.
For Telco/ISP/Wifi access point’s owner it adds another service to sell/provide besides internet access using existing billing infrastructure.
I will try to keep it as simple as possible, and to continue using existing open source components and protocols (HTTP, RFB, Google Native Client).
