André Kohn

> @jaked Great questions! I can answer a few of these for you. > > There are in fact [docs](https://www.npmjs.com/package/@duckdb/duckdb-wasm?activeTab=readme) for installing the library in a `vite` environment and they...

I'm sorry our examples are tested within the yarn workspace. I understand that this is unnecessarily complex, we need to make our examples independent of the monorepo to allow for...

@DnOberon makes sense, we should support that! But I'd propose to support HTTP headers through the "registerFileURL" methods instead. That would streamline providing credentials for other HTTP files as well....

Hey, there is quite a bit of work remaining depending on the feature set that you're asking for. If you'd be searching for a bare-bone duckdb instance without http filesystem,...

We don't officially support threads at the moment as SharedArrayBuffers are too painful. The bundle feature exists for our experiments but you shouldn't use it today.

Thanks for reporting this. That's a bug in the shell. DuckDB-Wasm itself will return an arrow.Map_. https://github.com/duckdb/duckdb-wasm/blob/ffa9210415e394fa84f0c769a54ef86b169bc2ab/packages/duckdb-wasm/test/regression/github_448.test.ts#L18-L33

Indeed, that sounds useful. I wonder if we could keep that on the Typescript side during URL registration. E.g. something like the following would be rather easy to do: ```typescript...

Sure, I was just referring to the way this would actually be used. Things like the http username would never make it SQL text then which would make this very...

Hm, I'm not convinced that `(url: string) -> data` would add too much value. The current API already allows to register Blobs so if the data is to be fetched...

I think this differs significantly from what vega is doing. If we go for the loaders, I'd definitely favour fine-granular chunk-wise loaders + the clear statement that everything beyond should...