coord-e/livr.md

## livr.md

      
    Raw
  

              livr.md
            
          
    The Lightweight Interactive View Representation

(pronounced as 'liver'!?)
Fast to show, in every platform.
Use cases


Browser
Rendering daemon which produces Livr from html
HTTP
Response Livr instead of html for faster rendering
UI
Common UI representation for every platform
Interactive Image
Use like 'Interactive GIF'
Office Suite
United standard of rich document format
And more, and more!

Features


Standalone
Just show it. done. All resources are in it.
Fastness
Fast to create, fast to view.

Specification

store as msgpack.
meta:
 title: Hello
 <thumbnail等>
body: |
svg or something...
placeholder:
  identifier:
    where: <Place spec>
    default: <body>
dynamic: <js code, ID=identifier replaced>

課題


DOM操作の置換
v8組み込み変数をW3Cに従ってGUI的に書き換えてグリグリすればいいんだろうけど、、、どうなんだ？
実際それでは「速い」とはいえないかも。


動的部分、静的部分
静的解析が必要になる。固定DOMはほんとにガチガチにして圧縮。もうSVGでいいよ。


CORS


目標は？


HTML -> Livr -> ViewがHTML -> Viewと同品質になる。Webアプリが動く。(それはデータ量が少なく、なるべく早い)

レンダラ

https://github.com/lexborisov/Modest か？
WebKit/Blink/Servo使いたいけどなぁ...
https://github.com/wkhtmltopdf/wkhtmltopdf
この実装参考にする。
DOM操作列挙し、操作外をSVG化、操作内をplaceholder化する
過度に一般化し過ぎでは問題

やりたかったこと→chromium撲滅→手段としてのrenderd+IR

State → Input(loaded) → Rendered Livr(depends on state) とかは。画面サイズ変更とかでもstate変更でok.
結局クライアントが処理しすぎだな。それが一極集中しただけだしもしかしたらSPAの部分レンダリングのがはやいやもしれぬしそもそも多重レンダリング大杉
問題

chromeのタブごとのプロセスは何やってんだ!?!?お前見えてないぞそもそも
レンダラが常駐しなきゃいけない理由はなにか
-> JSによる動的更新が起こりうる
Webページは"止まらないもの"かつ"相互作用的(ユーザーに限らず、プッシュ通知など)"
→次の表示は予測不可能
共通化はできっこない
問題

なんでもクライアントサイドでやろうって風潮あるけど、頭大丈夫か？>SPA
普通に考えて鯖が楽しちゃだめでしょ
だが、鯖にやってほしい"仕事内容"はユーザーの操作に依存する。
X転送かよ

勝手にやってろ