An ongoing thesis project - Cloud computing OS [unfinished]

Hi there, I posted a while back that I was going to create a Cloud computing OS similar to eyeOS. and so far, this is what I have, I would gladly appreciate it if you guys could take a look at the codebase and contributing if you want to…I plan to continue this project after I finished my thesis course…

I am having problems with database handled sessions and tokenizing it, so I’d be glad if someone could help out…

here is the github repo
http://github.com/jmrocela/dev-nimbus

requirements
PHP5.3 with sqlite enabled

oh you could also download the appfiles from
http://dump.iamjamoy.com/datadir
oh, create a folder above your root directory named .nimbus and put the appfiles from those folders above there.

If you could suggest things, or help out…I’d gladly appreciate it…:slight_smile:
yes, I am going to be serious about this project as the only application I know of that is of the same endevour is eyeOS and they have been taken in by IBM already…and no, this project is still under development…i just like input from professionals if I am on the right track…thank you in advance…

I know next to nothing about Cloud computing, and I’m far from being a database expert. But sqlite is just that, “lite”. It may be easier to install, take up less resource space, etc. and it’s fine for many uses (usually development).

But as you are experiencing problems with “database handled sessions”, I’m wondering if it’s too lite for your needs. Ideally you should probably make it to work with more than one database, but if you must commit to only using one, perhaps a more powerful (and complex) database would be a better choice.

Oh, it’s the implementation of the session, Its pretty silly but I am having problems testing with that…:slight_smile: thank you for the suggestion, but i stuck with sqlite so that the system won’t be caught offguard by an overloaded sql server…also, i heard that it’s faster than mysql in some scenarios…

Basing your choices of technology on hearsay is dangerous.

One problem with sqlite is concurrency. This probably makes it a pretty bad choice for session management. Or so I heard.

Why not use php’s default file-based sessions?

hi there,

the system doesn’t basically use concurrent database transactions. the system only uses one instance of it every use. and about session handling, it works right now, I just need the session to be logged and associated to a user id in the database…i’m looking into dropping that implementation altogether though.

thank you for the head’s up kyberfabrikken…i read about sensitive topics like those too, thank you for your advice…:slight_smile:

One thing did notice is that the Session::write() method only performs plain inserts into the session table.

I think that should be using inserts with conflict resolution, INSERT OR REPLACE (or just plain REPLACE).

Otherwise any data put into session after its has been created will not be updated.

thank you so much for your input, it could be the key to everything i’ve been missing about that piece of code…thank you…i’ll update it when I get the chance…

Sure, but if there are concurrent requests to your application, then you would also have concurrent connections to the database.

For that you don’t need to store the actual sessions in the database. You can just associate the session id. The main reason for implementing a custom session backend is for scaling out to multiple web nodes. Most php applications don’t need that kind of setup.

hi,

Sure, but if there are concurrent requests to your application, then you would also have concurrent connections to the database.

Right now the need for concurrent connections are not seen as a priority, but I do plan to support mysql as well as sqlite in the future

For that you don’t need to store the actual sessions in the database. You can just associate the session id. The main reason for implementing a custom session backend is for scaling out to multiple web nodes. Most php applications don’t need that kind of setup.

I guess you are right, but it is a good start to do it like that right? it’s a pretty complex system after all…well for me it’s complex…:slight_smile: thank you for your input

I don’t think so. It’s trivial enough to add later, and until you have the actual need, it’s premature optimisation. For a smaller setup, you may actually find that it introduces errors and hogs performance. For example, you’re putting more load on the database this way. That’s most likely more expensive than going straight to the file system.

thank you for your informative replies…but I will stick to the original specification for the meantime, the database accessor is pretty abstracted so integrating a mysql implementation wouldn’t be that too hard in the future.

for now, i’ll stick with sqlite…:slight_smile: i’ll punch myself when I encounter problems about sqlite, you can count on that…