Difference between revisions of "Architecture"
m (Logging Infrastructure) |
|||
| (25 intermediate revisions by 4 users not shown) | |||
| Line 3: | Line 3: | ||
Here will be a description of the architecture of WebOS Ports. How all bits and pieces interact with each other. | Here will be a description of the architecture of WebOS Ports. How all bits and pieces interact with each other. | ||
| − | + | [[File:LunaNext-Architecture-Diag.png|thumbnail|WebOS Ports Architecture]] | |
| − | + | [[Luna Next|Luna Next]] | |
| − | [[ | + | [[Logging Infrastructure|Logging Infrastructure]] |
| − | |||
| − | |||
[[Galaxy Nexus Communication Infrastructure|Galaxy Nexus Communication Infrastructure]] | [[Galaxy Nexus Communication Infrastructure|Galaxy Nexus Communication Infrastructure]] | ||
| − | + | [[Build Custom LunaSysMgr for OWO|Building Custom LunaSysMgr for Open webOS]] | |
| − | |||
| − | [[Build Custom LunaSysMgr for OWO|Building Custom LunaSysMgr for Open webOS | ||
[[GPU Drivers|GPU Drivers]] | [[GPU Drivers|GPU Drivers]] | ||
| Line 24: | Line 20: | ||
[[Porting_Guide|Porting Guide for new devices]] | [[Porting_Guide|Porting Guide for new devices]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
[[Input Method|Chinese, Japanese, Korean Input Methods]] | [[Input Method|Chinese, Japanese, Korean Input Methods]] | ||
| − | [[ | + | [[Submitting Contributions|Submitting Contributions]] |
| − | |||
| − | |||
[[Schedules/Beta Feature Plan|Schedules/Beta Feature Plan]] | [[Schedules/Beta Feature Plan|Schedules/Beta Feature Plan]] | ||
[[Secrets|Secrets]] | [[Secrets|Secrets]] | ||
| − | |||
| − | |||
[[WallpaperContest|WallpaperContest]] | [[WallpaperContest|WallpaperContest]] | ||
| Line 45: | Line 33: | ||
[[LS2_Debug_Commands|LS2 Debug Commands]] | [[LS2_Debug_Commands|LS2 Debug Commands]] | ||
| + | [[Upstream Submission Status|Upstream Submission Status]] | ||
| + | [[System_Upgrade|System Upgrade]] | ||
| − | + | [[Human Interface Guidelines]] | |
| + | == API Design == | ||
| + | Initially, we'll re-implement the webOS APIs. | ||
| + | We'll need some new APIs that are straightforward extensions of existing APIs (for example, [[Synergy_for_Tasks|Proposed Synergy for Tasks]]). | ||
| + | Other new APIs could substantially alter the app environment and user experience (for example, [[Intents|Proposed Lune OS Intents]]). | ||
| + | These must be carefully thought out, so they improve the environment for app developers and user. | ||
| − | + | When designing new APIs and data structures, favor URLs. For example, an avatar or attachment could be pulled from the net (http: or git: URL schemes) as easily as a file (file: URL scheme) or immediate data (data: URL scheme). | |
| + | A contact URL could be an email (mailto: URL scheme), IM address (im:, aim:, sms:, gg:, irc: URL schemes) telephone (tel:, skype: or rtsp: URL schemes) or a web page (http: URL scheme). Only schemes that make sense in a given context need to be supported. This will make our APIs and data structures more future-proof. | ||
| − | + | == APIs == | |
| + | Various info bits that still need further working out and documentation: | ||
| − | [[ | + | [[Permission_Service|Proposed Permission Service]] |
| − | [[ | + | [[OTA API Blueprint|OTA API Blueprint]] |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | [[ | + | [[Intents|Proposed Lune OS Intents]] |
| − | [[ | + | [[Synergy_for_Tasks|Proposed Synergy for Tasks]] |
| − | [[ | + | [[Swipe_UI|Proposed Swipe UI Convention]] |
| − | [[ | + | === Send URL === |
| + | A replacement for the Touch-to-share API is needed, which accommodates various transmission media, such as Bluetooth, ZeroConf (Bonjour), QR codes and [https://chrome.google.com/webstore/detail/google-tone/nnckehldicaciogcbchegobnafnjkcne Google Tone] or Chirp for iOS. The send side is probably best handled via the [[Intents|Share Intent]]. The receive side requires some thought: always-on is a security risk and wasteful of power, while activating a receive mode needs to be easy. It might or might not be useful to send or listen using several media at once. | ||
Latest revision as of 20:25, 7 June 2020
WebOS Ports Design Architecture
Here will be a description of the architecture of WebOS Ports. How all bits and pieces interact with each other.
Galaxy Nexus Communication Infrastructure
Building Custom LunaSysMgr for Open webOS
Chinese, Japanese, Korean Input Methods
API Design
Initially, we'll re-implement the webOS APIs. We'll need some new APIs that are straightforward extensions of existing APIs (for example, Proposed Synergy for Tasks). Other new APIs could substantially alter the app environment and user experience (for example, Proposed Lune OS Intents). These must be carefully thought out, so they improve the environment for app developers and user.
When designing new APIs and data structures, favor URLs. For example, an avatar or attachment could be pulled from the net (http: or git: URL schemes) as easily as a file (file: URL scheme) or immediate data (data: URL scheme). A contact URL could be an email (mailto: URL scheme), IM address (im:, aim:, sms:, gg:, irc: URL schemes) telephone (tel:, skype: or rtsp: URL schemes) or a web page (http: URL scheme). Only schemes that make sense in a given context need to be supported. This will make our APIs and data structures more future-proof.
APIs
Various info bits that still need further working out and documentation:
Send URL
A replacement for the Touch-to-share API is needed, which accommodates various transmission media, such as Bluetooth, ZeroConf (Bonjour), QR codes and Google Tone or Chirp for iOS. The send side is probably best handled via the Share Intent. The receive side requires some thought: always-on is a security risk and wasteful of power, while activating a receive mode needs to be easy. It might or might not be useful to send or listen using several media at once.