smalltall-samples into main
I've added some imperative code to show the minimal imperative streaming encoder.
Its Smalltalk, which is unusual, but Smalltalk has the least syntax of any language that I'm comfortable with.
2c8a12e930
to 56dffad682
56dffad682
to cfac9d789f
implementation". The distinction between functional and imperative seems a bit unnecessary to me. Naming the implementation by language seems clearer. Let's let other people decide what imperative and functional means.
I like that we include a Smalltalk implementation instead of C.
I've renamed the section to "Smalltalk-80 implementation". I find it very hard to distinguish what "imperative" or "functional" means. Let's just name the implementations by the programming language.
@ -1754,0 +1782,4 @@
<section anchor="exampleErisStore"
title="ErisStore">
<figure>
<preamble>A common implementation pattern is to use a semi-abstract object to represent a store of blocks. It should at miminum provide a <tt>get</tt> and <tt>put</tt> method and may also provide methods for handling cleartext blocks.</preamble>
Hm. I'm not sure if this is an abstraction we should introduce in the specification (even if in the appendix).
How about adding an Object BlockStorage that only has a get and put and does not do any encryption (move crypto to ErisEncoder)? This would make the BlockStorage object correspond much closer to things described in section 3.1 Storage and Transport Layer.
I think it would be nice to also include a random-access streaming decoder. In my experience, this is much trickier than the streaming encoder. Do you think you could add a Smalltalk-80 random-access decoder?
I pushed a commit to make the code more readable and mostly refer to Smalltalk rather than Smalltalk-80 (I think its all -80 these days).
The ErisStore abstraction could be omitted but I think it is unavoidable in practice and if you are going to implement ERIS you should think about it as soon as possible. The crypto could be moved into ErisEncoder but I think its wise to specify it only once at the common abstraction.
A random-access decoder is missing but I don't know of one yet, either I find one in the existing implementations or I write one from scratch in Squeak.
The
ErisStoreabstraction could be omitted but I think it is unavoidable in practice and if you are going to implement ERIS you should think about it as soon as possible.
I agree that some kind of abstraction is necessary.
The crypto could be moved into
ErisEncoderbut I think its wise to specify it only once at the common abstraction.
Hm, this I don't quite understand.
If you have want to store blocks in SQLite and also IPFS you might have two objects: a SQLiteBlockStore and an IPFSBlockStore. Wouldn't it make sense that these objects do not have to implement ERIS specific crypto?
Maybe you mean that both SQLiteBlockStore and IPFSBlockStore can both inherit from ERISStore and get the crypto like that?
Wouldn't it be a more clearer distinction to keep all ERIS related crypto in ERISEncoder and let the BlockStore objects just implement "stupid" block storage?
Sorry for missuing terminology. I am not so familiar with object-oriented/SmallTalk terminology.
A random-access decoder is missing but I don't know of one yet, either I find one in the existing implementations or I write one from scratch in Squeak.
I think it would be good to have a random access decoder. This seems to be the most tricky part about implementing ERIS.
On another note: Would you be open to including a Python implementation instead? I'm afraid I don't feel comfortable reading Smalltalk. Python is something we both read and write. Or maybe StandardML? That has the advantage that the language is synctactically simple and semantically well-specified.
Maybe you mean that both
SQLiteBlockStoreandIPFSBlockStorecan both inherit fromERISStoreand get the crypto like that?
Right, this is what I meant.
Wouldn't it be a more clearer distinction to keep all ERIS related crypto in
ERISEncoderand let theBlockStoreobjects just implement "stupid" block storage?
I think there are occasions where you need something other than then stock ErisEncoder and so it is better to move the crypto to a more base object/interface. It's a language specific thing.
A random-access decoder is missing but I don't know of one yet, either I find one in the existing implementations or I write one from scratch in Squeak.
I think it would be good to have a random access decoder. This seems to be the most tricky part about implementing ERIS.
Agreed.
On another note: Would you be open to including a Python implementation instead? I'm afraid I don't feel comfortable reading Smalltalk. Python is something we both read and write. Or maybe StandardML? That has the advantage that the language is synctactically simple and semantically well-specified.
Python I don't know well and it and Go feel like languages that are ostensibly simple but to write competent code you are expected to act on common superstitions on how the runtime is implemented.
I agree Smalltalk is an odd choice but something about the language made me choose to implement the efficient encoder right-the-first-time where as in Nim I did something slapdash.
How about Ada? ;)
How about Ada? ;)
I like that! :)
Let's try and hack together an Ada implementation.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?