On 13 Jun 2019, at 09:00, Marcus Denker <marcus.denker@inria.fr> wrote:
On 13 Jun 2019, at 08:10, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Stephan Eggermont <stephan@stack.nl> writes:
All of http://files.pharo.org/ ? So how many GB is that?
It is only a few thousand changes per release. There is no reason why that shouldnât compress well
Did anybody try?
In IPFS, files are cut into blocks of roughly 256 KB. Blocks shared between multiple files are stored only once. So if changes in Pharo images from one version to the next happen mainly in one or two specific places (such as beginning and end), they would be stored efficiently on IPFS without any effort.
But again, the best way to know is to try it out.
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?
This way we could have one âfullâ copy and caching (e.g. in the âAfrican class roomâ example) would happen automatically.
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â¦
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â? - How could one move resources out of the image into IPFS? - Content addressing (like it is done in Git, too) and Objects, how can it mix? â Could one have âcontent pointersâ instead of âmemory pointersâ? I am sure there is much more⦠Marcus