A complementary Haiku web application persona

[jonas.kirilla]

If Haiku was remade to be consumable as a website, both locally and remotely, if redesigned as a kind of middleware for running Haiku web applications (called haikus?) this could:

• free it from the present consensus against theming
• free it from the constraints of its C++ API
• free it from limitations of the app_server (drawing primitives?)
• free it from the conventions of its desktop environment (Tracker, Deskbar, Twitcher, etc)
• mitigate the lack of drivers, if consumed from another computer
• allow accessing one's Haiku environment from one's phone
• eventually free Haiku from dependencies on its own kernel and filesystem
• make multiuser more interesting (to experiment with)
• sidestep C++ API integration for script langauges, offering web-based GUI
• allow apps to mix different programming languages
• allow apps to offer services, data to each other

All in all, this would help break Haiku out of its current pigeon hole. It might not be Haiku anymore, but it would be more interesting, to me at least. BeOS fans learned to love the post-BeBox BeOS. "It's dark in the box." Perhaps Haiku fans can learn to love a post-Haiku Haiku, if its spirit, core values, sensibilities, and ease of use remain.

To be clear, for a transitional period of time (years, most likely), the present Haiku would be the premier host platform for its web personality. Haiku weblets would be shown as regular windows when run locally. Remote web consumers would only see the haiku weblets, and weblet windows would be managed by a pluggable window manager, similar to X in concept, tailored to a web user experience when used remotely.

​http://haiku-os.org/community/forum/it_time_complete_os_visual_redesign#comment-30235

[waddlesplash]

-1 from me overall, but specifically:

• Haiku has "decorator" support, and there is a way to theme the default controls (BControlLook) it just needs a bit of work to be able to do the 100% visual makeover that's possible elsewhere
• C++ is nice. Getting rid of it would require rewriting 99% of Haiku. That's not the scope of this project.
• app_server's limitations are merely the result of lack of developer time to add features, that's all.
• Haiku is and hopefully always will be a desktop OS. If we go mobile-only, count me out. Supporting ARM is great, adding a touch-based UI is not the scope of this project. (Supporting touchscreen laptops is, but only insofar as touch-to-scroll, etc.) Third-party apps welcome (but won't be default nor included by default).
• That doesn't help, we'd still have to write drivers to get the OS itself booting. If you can run a web stack, you can run everything else Haiku currently can do.
• Also not the scope of this project. Third-party apps welcome.
• Huh? How do you write an OS without a kernel?! Are you saying that we reduce Haiku to an application, not an OS?
• Multiuser is on the TODO list for R2, we already are committed to doing that (the kernel supports multiuser already, the userland just does not.)
• You'd still have to have C++ (or some other low level language) somewhere to interface with the hardware
• Not the scope of this project. See TideSDK or Breach's "Thrust", they already can do that.
• We already do this (media_addon_server, DataTranslators, "hey", cross-app BMessaging, etc.)

This is not the Haiku I want. This is not the OS I want. Sure the web is nice, but I like having native apps too.

[tangobravo]

This is a pretty ridiculous ticket. It's definitely not an "enhancement" to Haiku, and should be closed as invalid IMHO.

Jonas, I've seen you mention this grand plan on the mailing list before, and in some ways I can see an argument for why it might be a more relevant project for today than a recreation of BeOS. However it is clearly an entirely separate project from Haiku.

[X512]

Someone implemented remote desktop functionality for app_server with HTML5 client. This functionality allows desktop access to Haiku server throught web browser without plugins. I don't know is it work or not.

​http://cgit.haiku-os.org/haiku/tree/src/servers/app/drawing/interface/html5

[jonas.kirilla]

Replying to tangobravo:

This is a pretty ridiculous ticket. It's definitely not an "enhancement" to Haiku, and should be closed as invalid IMHO.

Jonas, I've seen you mention this grand plan on the mailing list before, and in some ways I can see an argument for why it might be a more relevant project for today than a recreation of BeOS. However it is clearly an entirely separate project from Haiku.

It is, and feel free to do so. I mentioned it once on the mailinglists, once on the forums and thought I should log it formally. I suppose it can be taken as absurd or even insulting and that you have to have a certain detachment to appreciate it.

The idea itself could just as well be implemented on Linux or some other platform, but if Haiku could live through the change it could benefit from being the first and position itself better for the future. If there is merit to the concept.

The main thing here is to make it easier to bundle any combination of native code, script languages, networked data, as coherent apps, and make it consumable. In my mind it follows along the evolutionary trajectory of the package fs, and does for execution what the package fs does for storage. But I guess from the pragmatic point of view, this is all just rambling.

[pulkomandy]

Hi, This is so different from Haiku it's time you create your own project. But please use a different bugtracker for it.