Not today, but the architecture isn't fundamentally incompatible. The page grouping and seekable compression would translate well to browser fetch + range GETs. It would need a new storage backend targeting OPFS/fetch instead of S3/disk. I'm happy to discuss more if you'd like to open a Github issue - abstracting the storage API seems like a decent idea in itself.
correct it will be handled via backend which will just proxy requests to R2(its S3 compatible). i already have something working with vhttpfs but you have implemented some great ideas like optimizing request count instead of byte efficiency, i wanted something like that in vhttpfs but it will become another project for me.
I think it can be great frontend tool as well since you have decoupled storage with db engine.
Not today, but the architecture isn't fundamentally incompatible. The page grouping and seekable compression would translate well to browser fetch + range GETs. It would need a new storage backend targeting OPFS/fetch instead of S3/disk. I'm happy to discuss more if you'd like to open a Github issue - abstracting the storage API seems like a decent idea in itself.
Also I'm curious how you would handle credentials - would you be proxying through your backend? To me turbolite is definitely a backend tool.
correct it will be handled via backend which will just proxy requests to R2(its S3 compatible). i already have something working with vhttpfs but you have implemented some great ideas like optimizing request count instead of byte efficiency, i wanted something like that in vhttpfs but it will become another project for me. I think it can be great frontend tool as well since you have decoupled storage with db engine.