[haiku-development] web tech as R2 prototyping ground
- From: Jonas Sundström <jonas@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 11 Feb 2014 06:29:37 +0100
I would like to suggest using web technology as a Haiku R2 prototyping ground,
and to use Google Summer of Code to produce the necessary implements.
Why would anyone want this?
1. Evolution, carefully. Haiku needs “glass elevator” to came back, but the
project can not afford any more disruptions right now.
2. Inclusion. More people could contribute in a meaningful way with web
technologies than they could (or think they could) with C++. And they could do
so independently of the project. We could have a multitude of Haiku look & feel
without breaking the core platform.
3. Reach. It might enthuse a segment of users and developers who's potential
we're not taking advantage of currently.
4. Vision. Seamless integration of apps and data sources?
5. Architecture. Decoupling of user interface and data/services backend?
This should enable running web applications on Haiku alongside native apps. If
carefully implemented and with proper support in WebPositive it could appear to
be seamless.
Thinking beyond self-contained web apps (e.g. delivered through WebPositive)
and envisioning a local web of apps and data sources, a portal or desktop like
web would open the platform to user interface customization. Without breaking
the fundamental design of the system. Without changing its basic look and feel.
Without upsetting the BeOS diehards. You could try new user interface designs
on Haiku without API changes. And people are likely to have a less steep
learning code with HTML, CSS, script languages and e.g. jQuery than they have
with C++.
Necessary components:
* Web app server.
- to listen to requests and launch web apps.
(like ‘inetd’)
- to coordinate web applications (authorization, capabilities?)
(like Registrar)
- to deliver content to clients (local and remote?)
(like the AppServer)
* WebPositive
- being the tool to consume web applications
and interact with the webbed version of the system,
with entry points for applications, for data sources,
for portals or desktop environments.
* Webbed apps
- a single app could publish multiple entry points.
It would answer to all URLs, below its web app address root,
but only some of these URLs would be considered entry points,
and be enumerable:
A webbed StyledEdit might publish
- one entry point for the app
- one entry point per open document,
- one entry point per recent document
- one entry point for its prefrences, etc.
- bookmarks to local entry points of an application
(or a data source, the distinction is blurred)
- opens in WebPositive or a streamlined version of it,
so as to make it appear as if it was a Haiku application
like any other.
By taking out the need to create GUI API bindings for the desired
languages, leaving the GUI to the browser and data exchange to
networking, we can get things off the ground gradually.
Ideally you would be able to take this webbed Haiku environment
fullscreen and use webbed remakes of Deskbar, Tracker, the preflets,
and all your favorite applications.
This webbed Haiku platform could be made simple or more involved,
depending on if one wants it to be remotely accessible, or by multiple
concurrent users.
It could be made independently of Haiku or closely integrated.
Could be suitable as a GSoC project.
What do you think?
/Jonas Sundström
Other related posts:
