Hi all,

Mercury is the tentative name I gave a technology I've been working on. It mimics an OS-like environment on your Browser.

You interact with it in much the same manner you would with any regular OS.

My vision is pretty much "your apps - online", where anyone can run them, in an environment that is easy to develop for, coder-friendly.

Here is the link for video 1:

">YouTube

Please watch it and place your doubts and questions here.

Thanks for the feedback and any interest in the Project.

(PS: Also looking for beta-testers)
(PPS: Also looking for employment...)

...really need your feedback guys :)

Wow, that's cool. Is there an open api to write applications for it? Do applications run mostly in &#106avascript or mostly server side?

Very impressive. Can you show us what is involved in writing an application?

@choffstein: The "backside" of it? Well, Mercury is an agregation of various technologies: PHP, &#106avascript, Ajax, Json, HTML and CSS.

Mercury allows a user to run applications in a windowed environment. Each application has its own code file. This code file consists of:
* HTML - defines the structure of the application, in the form of text, controls, etc.
* CSS - gives the HTML unique styling. A parser engine ensures that no two applications share the same CSS styles.
* &#106avascript - runs when the window is created, setting it up. Programmers will be able to setup an endless amount of options, for example, the label text (name of window), the Status Bar text (footer of the window), what system buttons appear (menu, minimize, maximize, close), callbacks for Events (onKey, &#111;nResize, &#111;nClose, etc).<br>* PHP - runs when the window code file is parsed, allowing the application to access the DataBase and set itself up<br>* Ajax - &#106avascript code that allows the Client-Side of an Application to talk to its own Server-Side (PHP). The Ajax engine of the Window has been fully wrapped, and it's a breeze interfacing your client-side code with your server-side code.<br>* Json - Preferred format for data interchange.<br><br>So, a single file allows us to define the structure of the windows (HTML+CSS), allows us to talk to the database (PHP) and allows us dynamic interactions &#111;n the User's machine (&#106avascript).<br><br>Furthermore, two OS classes exist:<br>* A &#106avascript OS class that wraps all of the operating system functions, like, creating a new window, logging &#111;n/off, listing a User's applications, managing the workspace, garbage collecting when a Window is closed, etc;<br>* ...and a PHP OS Class, that offers various help functions, like DataBase access, accessing a User's private data (in Mercury private data is valuable, and there will be filters so that the application cannot access your private data without clearance), management of Files (delete, move, rename), etc, etc, etc...<br><br>By the way, if you haven't figured it out by now, let me explain that, when you click over an Application in your App List, the system fetches everything related to that application via Ajax. This means that when you open the Mercury window, there is literally no applications present, and whatever the User requests, is fetched from the Server in a dynamic fashion.<br><br>Each application is "rendered &#111;n demand" via an Ajax engine, that fetches the application data from the Server, parses it, and then displays it &#111;n your Browser.<br><br>Mercury also has the concept of "processes". These are pieces of code that run &#111;n Mercury's operating system, mostly client-side (&#106avascript therefore) but have no attached window. As an example of two processes, we have:<br>* p_Clock - Renders/Updates the system Clock<br>* p_UserActive - This process ensures the User has been active using Mercury for the past X minutes. If the User is absent, depending &#111;n it's configured Settings, the User may be logged out, or the screen saver might be activated. This ensures no &#111;ne has access to your work area if you've gone out to lunch and forgot to log off.<br><br>There are also Server-Side Processes. These are attached to a CRON Wizard, and self-schedule at specific intervals to perform maintenance tasks. They are of course PHP-based.<br><br>I want as much abstraction, when writing a new Application, as possible. I want the programmer to have a really easy time coding in Mercury, and leting the OS worry about the mundane stuff, like, the Ajax engine, basic window interactions, etc. The programmer will have a bunch of User-Interface controls he can almost literally drag and drop &#111;nto the code that will make his application more fluid and atractive.<br><br>I'm also designing a module that will allow an application to be localized, by querying the browser's prefered language. In other words, if a User has set its browser to prefer French, and if an Application has a French localization table, then when the User calls up the Application, it will be instantly rendered in the User's prefered language, French.<br><br>The User will also be able to set his prefered language and other settings in Mercury's Config Panel. Everything, from prefered Date format, decimal symbol (comma or dot?), prefered Units (grams, pounds, meters, miles, inches, etc...).<br><br>Once those are set, the system will have enough intelligence to auto-translate text tags in forums and articles. If someone writes a cooking recipe in European units (grams, liters), the system will auto-convert the units to your preferred settings.<br><br>If you run the Treadmill App, to track your treadmill training sessions, and you're European, it will display the Units as Km/h and Kg. If you've set your preferences to Imperial, then you'll see miles/h and lbs.<br><br>If you open a diet forum and someone has written "I currently weight 110kg but this week I've ran 8km!", and your preferences are US/Imperial, what you'll actually read will be: "I currently weight 242lbs but this week I've ran 5miles!".<br><br>Much of all of this is already in a very, very advanced stage of completeness.<br><br>@Sneftel: Thanks for the tips, I'll really have to look into Google Gadgets and other similar pre-made applications. I'll try to add some sort of OpenID or LastPass to the system. People are really getting tired of so many passwords they have to juggle in their mind.<br><br>@marc40000: See above for your response. There will eventually be an open API yes, but that will also require a sandbox server. Programmers develop their apps there, and &#111;nly after they've matured and are stable, they go through an approval procedure. This approval procedure isn't some form of Draconian control set up by me, no, not at all, it is all about the User and his privacy, therefore I must ensure that the Application's code obeys the API, accesses &#111;nly the data it should access, and doesn't "leak" data.<br><br>In Mercury, quite unlike the trend in various current social sites, every data you create or resource you upload is Private, and can &#111;nly/will &#111;nly be shared after you specifically instruct Mercury to do so.<br><br>@rip-off: I'll do a video later this week if the time allows it, detailing the creation of a "DailyWeight" application, to track a User's weight throughout time, and have the ability to seamlessly create a graph chart showing Weight variations across time, using <a href="http://pchart.sourceforge.net/">pChart</a>, that has already been integrated into the PHP OS Class, and so with a few basic calls, you can have your graph dynamically generated, and then delivered to you via Ajax.<br><br>If you're thinking this all sounds really complex, the low amount of code required to achieve it will most assuredly impress you.<br><br>Please keep the feedback coming!

Yes, very cool. I'd be showing that to Google, Microsoft and Apple.