Hoping to get an idea what could be useful to others. If anyone is working on something behind the scenes please let me know so efforts are not duplicated.
Cheers!
A library to simplify handling linked lists of entries would be cool and useful. An ordered list of entries with connected data entries to each entry. I would like to be able to reorder the list, insert, delete and replace entries. And update (replace) the data entry.
Something like this:
I came across this need yesterday trying out some ideas. Definitely think it could be made into a library.
A library like that also could include other common scenarios for organising entries and their data.
3 Likes
Until recently, I actually was tracking different projects and common needed zomes for them here: https://miro.com/app/board/o9J_kiCYe6Y=/, and some of them are already scaffolded and have working PoC here: https://github.com/holochain-open-dev
I can give descriptions of any one module if it catches your attention. However, I don’t think I’ll be further developing these modules, as I want to transition more into building guides and tools for people to be able to develop them themselves. I’m always open to have conversations around these modules.
There are some other common libraries, maybe not fully fledged zomes, that could be very useful:
- Time indexing
- Invitation membrane
- Password membrane
- Geolocation indexing
- Full-text indexing
@kristofer, could you explain a little bit more about the linked list of entries stuff? I don’t quite understand the use case.
2 Likes
Sure @guillemcordoba. Let’s say I want to build an app that manages food recipes.
Recipe for Cake
- 2 eggs
- 1 cup sugar
- 1 cup milk
- …
Requirements:
- Each line in the recipe is represented by an entry.
- Easy CRUD of entries.
- Ability to order and reorder entries any way I please.
- Ability to change entry data without replacing the id the UI uses to reference that entry. Viewed from the perspective of the UI, it is still the “same” entry.
A linked list of entries with separate data entries as described on my sketch fulfills those requirements. I’m sure there are other ways as well. Perhaps this is more of a design pattern than a potential library. But, a library that makes implementing different holochain design patterns easier could help new devs get up to speed a lot. Helper functions, trait implementations, macros for this and other design patterns: mailbox, progenitor, lobby, etc.
1 Like
Yeah okey I see.
I think about these kinds of things as design patterns more than libraries really, because I think it really depends on your use case and what trade-offs in regards to performance you are willing to make.
Like in this example, I would probably not implement this as a linked-list of entries, but just have two types of entries: “Item” and “Recipe”, and have the recipe entry be something like:
struct Recipe {
items_hashes: Vec<EntryHash>
}
Because then I don’t have to keep creating and deleting links, and I can keep track of the order of the items much better than if implemented with links.
As far as the updating goes, I agree, but again it depends on the use case. One of the key things here is that in RSM, to update an entry you have to update the header, not the entry itself. So you want to probably have the header hash in the UI as well, this is how Acorn is doing it. Some libraries implementing different use cases would be helpful here, the first one being hc_utils, which already contains opinionated update logic.
As far as the progenitor and things like that goes… I’m curious, in the membrane roles module I am assuming the progenitor pattern, here is its code. Do you think it’d be useful to split that into its own library and have zomes depend on it? It’s such a small thing and people might want different things out of it that I don’t know whether that’s best or not.
2 Likes
I’ve been advocating for a sorted linked-list kinda integration in Holochain itself for ages… But considering that it’s not too hard to implement with the existing tools at the disposal (linking, unlinking and stuff like that), I don’t think we’ll get a library or native integration for this anytime soon… Not that I don’t advocate for one; it’s just that it’s unlikely that we’ll have an easier, more efficient way to do this anywhere in the near future. However, I do strongly advocate that it be recognized as a standard pattern, and that there be some standard convention established by the core-team on how to approach this oneself.
1 Like
Agreed. A continued discussion about design patterns for distributed, agent centric applications will be important to help the ecosystem of developers grow. Probably documentation and identification of best practices is more important than helper libraries.
2 Likes
Yes, there will definitely be room for more of that. Low level, opinionated libraries helping you quickly scaffold your data structure and crud logic.
Yup, sure, that works well when the list is short, like in a recipe. It’s just me wanting to minimise data duplication. If instead, each item would represent a line in a long text document it would feel awkward to duplicate the Vec on each change.
Hum okey, but I think I would much rather have a long list of duplicated hashes than doing it with links, which is less performant both in DHT Ops and weird when you update the recipe entry, if you have to keep adding and deleting links reading updates is going to be slow. It also feels inconsistent, specially with reordering of items for example.
Anyway, overall I feel we need to do a better job for devs and architects to understand the underlying patterns and mechanisms that you have available and how to play with them, more than exposing best practices libraries… Those are necessary for sure, but as a developer you need to know what library/pattern to use that fits each use case. I might be wrong about this though… I want to play and experiment more.
3 Likes
I think we have two different, but familiar, design patterns here. If I got it correctly @kristofer did propose a pattern to create hierarchical nested entries. In Postgres those are realised as ltree for instance. But you refer more to a solution of sequencing or ordering the entries. For sequencing a single integer field is all what need in the zome, the handling or handle comes with the UI.