Claire Foster

> I thought we'd discussed not using @! and making the context explicit instead. Yes, but then we decided to use finalizers instead, where possible, and not expose the context...

> That's what was implemented in #12 for Blob and BlobTree (which needed to become mutable as a result). Of course, the issue with the finalizer approach is that it...

> Return a mutable wrapper object, perhaps? Either that or if the object is immutable, throw an error and require the caller to use the explicit context form (or the...

> so I could a file that is encrypted + compressed, and layers would allow the program to peel this back to handle that on the fly? Yes, this should...

> Maybe something in the Data REPL to show the active project We have this — I guess it's just badly named: ``` data> stack list DataSets.StackedDataProject: DataSets.ActiveDataProject: (empty) DataSets.TomlFileDataProject...

Well `Blob` is already a lazy handle to potentially-remote data where the actual data fetching is delegated to a storage driver instance. So technically `Blob` is fine to serialize, it's...

> refetch it on first use or on deserialization? Yes that's what I meant by > transparently hook up any serialized Blob to the local data cache during deserialization This...

Right, this version of `open()` isn't defined - instead, you can use `open(func, T, dataset)`. In your case `open(io->CSV.read(io, DataFrame), IO, dataset("us_counties"))` Possibly we could define it; we'd need some...

You don't need the intermediate stage where it's opened as a blob, you can just open `Blob`s directly as a more Julia-native datatype you care about. For example, `CSV` prefers...

In general, the idea here is that `Blob` is a reflection of what's on disk (vector-of-bytes), but that this can be reflected into Julia in various ways - at least,...