I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.
The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).
In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .
People building these Rube Goldberg contraptions: Do you actually run evaluations if this is any better at all than eg. giving it access to a Python REPL, or just toughing it out with random tools composed via shell scripts?
Why would an LLM be better trained to access Redis via a FS vs. a native library API?
I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.
Take this, for example:
> s3.put_object(bucket, key, data) -> cp file /s3fs/bucket/key
The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).
In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .
People building these Rube Goldberg contraptions: Do you actually run evaluations if this is any better at all than eg. giving it access to a Python REPL, or just toughing it out with random tools composed via shell scripts?
Why would an LLM be better trained to access Redis via a FS vs. a native library API?
Makes no sense.
Why are you upset?
More LLM focused crap.