This project replaces those with RESTfull (CRUD?) operations. But this repository also seems to define what 9p does not, the structure of the data. It defines what files to write to and what to write to them. That seems outside of the 9p scope as you are defining the service behind the transfer protocol.
A RESTfull API to attach to a 9p backed does seem useful since the support for RESTfull API's is so huge. To me it's unclear how this monolithic approach is beneficial above a "RESTfull to 9p" proxy and a 9p service.
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?
> Why would an LLM be better trained to access Redis via a FS vs. a native library API?
Limiting the potential blast radius.
If you give an agent "access to a Python REPL" (your words), you're giving it access to all of Python. i.e. you're paving the road to your own destruction when the agent goes awry. In the case of a Python interpreter, you're basically handing it an eight-lane highway upon which all sorts of pile-ups and havoc can happen.
By limiting its access to specific operations via well-defined endpoints (which is what the AGFS approach is), you're trimming that eight-lane highway back to a bicycle path.
I may interpret this wrong, but the 9p protocol describes transfer protocol operations not data structure.
9p defines filesystem operations: attach, walk, open, create, read, write, clunk, remove, stat. And some additional handling operations: version, auth, error.
This project replaces those with RESTfull (CRUD?) operations. But this repository also seems to define what 9p does not, the structure of the data. It defines what files to write to and what to write to them. That seems outside of the 9p scope as you are defining the service behind the transfer protocol.
A RESTfull API to attach to a 9p backed does seem useful since the support for RESTfull API's is so huge. To me it's unclear how this monolithic approach is beneficial above a "RESTfull to 9p" proxy and a 9p service.
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 would an LLM be better trained to access Redis via a FS vs. a native library API?
Limiting the potential blast radius.
If you give an agent "access to a Python REPL" (your words), you're giving it access to all of Python. i.e. you're paving the road to your own destruction when the agent goes awry. In the case of a Python interpreter, you're basically handing it an eight-lane highway upon which all sorts of pile-ups and havoc can happen.
By limiting its access to specific operations via well-defined endpoints (which is what the AGFS approach is), you're trimming that eight-lane highway back to a bicycle path.
Why are you upset?
More LLM focused crap.