Marcus Denker <marcus.den...@inria.fr> writes: > Indeed. Another thing to try: if someone has a local IPFS running, would it > cache > only those images that either this machine or near machines requested?
Yes. But note that "nearby" is probably not what you expect, since IPFS connects more or less randomly to other peers in the network. It's neither geographically nearby nor nearby in the local network. All that can be configured. > This way we could have one “full” copy and caching (e.g. in the “African > class room” > example) would happen automatically. That might work. A safer approach is to have one server machine in the classroom on which the required files are pinned (IPFS jargon for "not removed during garbage collection"). Then configure the other machines nearby to "bootstrap" from that server. > Of course the downside is that one needs to speak the IPFS protocol, > thus either running a client (e.g the go client)… so real transparent > use would only be possible if Pharo could implement the protocol… The generally recommended way to use IPFS on a desktop machine is what I do in my Pharo interface: connect via HTTP to go-ipfs running as a daemon process. Even the IPFS command-line client does that. The advantage is that you have only one data repository per machine, rather than one per process. For getting a Pharo image, you would then use the command-line interface, or implement IPFS access in Pharo launcher via the daemon (which should be straightforward, since it's really just an HTTP request). > There are many other ideas to explore (based on my partial knowledge)… > more brainstorming than anything else: > > - Could we have an image formate that would be “block friendly”? Probably. If some stable core is in one part of the image and the stuff that changes with each release in another part, then many block could be shared. Which IPFS does automatically. > - How could one move resources out of the image into IPFS? This is what I am currently experimenting with. My idea is to use IPFS as something like an extended image, mainly for data that I would also like to access from non-Pharo code. > - Content addressing (like it is done in Git, too) and Objects, how can it > mix? > — Could one have “content pointers” instead of “memory pointers”? It can certainly be done (just put all objects into a dictionary with the hash as the key), but memory efficiency and access time could be serious obstacles. This sounds more like a research project. Konrad.
