雑にやるなら KVS とか使えそうなんだけど、 read-only にするのか modifiable にするのかは考えないとなぁ

スレッドを表示

今のところ、これをベースに自分でモデル考えるくらいでいいかなという考えでいる

スレッドを表示

WICG/webpackage: Web packaging format
github.com/WICG/webpackage

WebBundle が規格になっていればよかったんだけど、まだ draft 段階だし……
あと広告関係で悪用できそうなテクノロジなので嫌われがちという欠点もある

スレッドを表示

で、どうせなら静的サイトジェネレータ的なもので WebBundle みたいな HTTP header aware なデータを生成して、それをサーバから垂れ流すみたいな感じにするといい感じに静的にできるのかななどと妄想している

スレッドを表示

じゃあなんでサーバを書くのかというと、 content negotiation まわりでどうしてもファイルシステムだと弱いのよね。
特定のリソースは Accept-Language のみ気にするかもしれないし、特定のリソースは Accept も気にするかもしれない。
で、それらに柔軟に対応するとなると自分で書くのが早い

スレッドを表示

Web サーバを実装しようとはしているけど、本当に必要な動的部分はせいぜい検索とか複数タグでのクエリ程度のものなんだよなぁ。それも事前のインデックスがあればクライアントサイドのスクリプトでどうにかできるかもしれないし。

UTF-8 mime-type constants don't work well with browsers' `Accept` header · Issue #371 · http-rs/http-types
github.com/http-rs/http-types/

むーん……

既存実装で何が満足できないかというと、主に thread safety まわりの制約が不必要に強すぎるとかがある。
たとえば内部的に Rc<RefCell<NodeImpl>> のようなものを使っている場合、 DOM を一度構築したら別スレッドと共有するのは困難になってしまう (何故なら Rc<T>: !Send なので)

スレッドを表示

つまり xpath とか xslt とかの実装も自前で用意したいという話ですね (白目)

スレッドを表示

ブログ markdown で書こうかと思ったけど諸々の要求を考えるとやっぱり XML でないと駄目なので、いっそ XSLT を記事毎に用意するくらいのつもりでカジュアルにホイホイ使えるようにエコシステムを揃えていくしかあるまいという結論に至った

スレッドを表示

というわけで次の四半期の融かし方が決まりましたね……

大変よろしくないことはわかっているんだけど、どうしても libxml2 の代替実装を pure Rust で書きたくなってしまった

from_ref in std::slice - Rust
doc.rust-lang.org/stable/std/a

std::slice::form_ref と何が違うんだ? と思ったけど、 slice の方は &[T] を返して array の方は &[T; 1] を返すのか。たしかにそうなるわな

github.com/lo48576/fbxcel-dom/

周辺部分は割合良い感じになったので、これから本命であるところの object 関係の API を本格的に設計していかないといけない (旧バージョンの設計は失敗だったので何か良い手を考えないといけない)

古いものから表示
Mastodon

Mastodon は、オープンなウェブプロトコルを採用した、自由でオープンソースなソーシャルネットワークです。電子メールのような分散型の仕組みを採っています。