Do you think your tech has potential to replace SE in all Autonomi?
3 Likes
The tech is covering the files and SE parts of Autonomi client. It definitely has the potential to replace it.
If it is considered to meet the team’s needs then they could “relatively” easy switch to it (i.e. since it is the client, the network doesn’t care about this part). Unless I’m somewhere else I’d probably raise a large number of the PR:s 
But, for that to be realistic, this tech has to prove itself. It has to run for an extended time, with many users in many different environments. The tech has to be shaped to easily drop in place in the existing Autonomi client (not a hard requirement, they’ll fix anything, but it lowers the threshold). It has to be well covered in documentation and tests. And, as said, meet their needs for their envisioned solution. Then, there could be a good case for them to consider a full replacement.
It may also be that they are happy for a third party to provide the tech, and they’ll either run their solution as a legacy thing (not actively promoting it), or keep it in parallel as an alternative.
They could also take inspiration from or adopt specific parts of the tech.
They could develop or expose their existing solution, or parts of it (like SE), into some other niche.
There are many ways.
I will definitely look at such things later, but right now I’m only focusing on designing for the Ryyn-case exclusively.
13 Likes
Hehe that’s what we call disruptive tech 
7 Likes
Do you have the concept of a .rynnignore file?
I’ve a couple of machines where I’d love to sync my projects across 
but maybe exclude a number of files/folders from this syncing
6 Likes
This is a great feature (which I think for example SyncThing doesn’t have).
Ignore-file seems like a practical approach.
I definitely will add that or an equivalent solution.
8 Likes
The cool thing about ignore files is they’re easy and hierarchical - I may want different patterns ignored on different levels
3 Likes
If you have ignore directory and its children directories then having a include is also needed. There are cases where the parent directory has nothing one wants but one or more of its children directories do
3 Likes
Yes, the gitignore pattern allows for that.
I was however looking to see if there could be better ergonomics, for both users and developers
Something like this, yaml based:
rules:
# Path-based rule
- path: "**/build/**"
action: ignore
Very simple and basically the same as a gitignore.
Then it could also be using attributes, for those who want more control
# Attribute-based rule
- path: "*"
if:
name: "secret.key"
action: ignore
- path: "*"
if:
extension: ".log"
size_gt: 100MB
action: ignore
2 Likes
Seems overly complicated for most. I like that gitignore and rsync are simple syntax that I don’t need to lookup and study on the rare occasions I mess with those settings.
Maybe have that with a managing GUI, but something simple for quick file based config?
4 Likes
I updated the post. Probably seemed more complicated than it is.
I was thinking about it from the perspective of users who do not usually handle such files, and without needing to add a GUI.
They need to lookup anyway, and this was covering for how one would have done this if doing it today.
Backend parsing still needs to be there
1 Like
One of the things, maybe the thing that makes it complicated is using Yaml.
Maybe once you understand it thoroughly it seems simple, but I don’t believe that Yaml is suitable for occasional or non users of Yaml.
3 Likes
Probably would best use a GUI for casual users anyway.
But for others, TOML would be better (especially than yaml, as you say) it’s less fragile than gitignore style also.
Generally, gitignore is not simpler per se (than what I was looking at) just familiar, both have their value.
We’ll see, will be something anyway.
Agreed. But mostly more familiar because it (and rclone lists) use motifs familiar from the shell and minimal other furniture that can get in the way. So you can’t easily make non-parsable instructions as with Yaml, so it’s much easier to fiddle about and try things.
1 Like
I wish to complain in the strongest possible terms.
Yo did not highlight the above in the largest possible BOLD text
Yaml is unsuitable for occasional or non users of Yaml
Fed up effing about with indentation that seems to make NO sense. I nearly entirely gave up on netplan - which is otherwise fine - cos of effing yaml.
Someone should make yet another markup language which is not yaml.
3 Likes
That’s good reason to use it.
It lacks some things that I think are important for backup, but I think it can actually be kept as an interface for those who prefer that style.
How about
Ignore: /etc
Ignore: /bin
Ignore: /home
Include: /home/me
1 Like
If I accidentally type
Ignore: /etc
Ignore: /bin
Ignore: /home
Include: /home/me
Will it refuse to parse it and offer ZERO help to sort it?
Be like command line processing, 10 white spaces is the same as one and leading white space ignored
The app should highlight anything that isn’t right
1 Like
Aside from syntax:
Say I want to ignore the entire cache/ folder tree, except for any important.txt files no matter where they are.
Also, if there’s a keep.json inside any final/ directory, I want to keep those too.
cache/
!cache/**/important.txt
!cache/**/final/**/keep.json
If cache/foo/ is excluded from cache/, then !cache/foo/bar/important.txt will not work. You’d have to do this:
!cache/foo/
!cache/foo/bar/
While you could instead do this:
[[rules]]
path = "**/cache/**"
action = "ignore"
[[rules]]
path = "**/important.txt"
action = "include"
[[rules]]
path = "**/final/**/keep.json"
action = "include"
So the difference is:
- No parent re-inclusion needed
- Refactor/move of folders and rules still hold
The syntax diffefence isn’t the thing, could use the same. But it would be confusing to use same syntax but different capabilities, so better to differentiate.
Regardless what syntax is used, if it’s easy to detect user intent, then type errors should not be in the way, if intent is dubious a very clear and actionable error message should be available (ideally).
2 Likes
you’re right.
just want to throw in that modifying gitignore/dockerignore files has been done without much discussion pretty fluently in between other changes in our team … but specifying rules for pipelines correctly and with the desired outcome has caused excessive discussions and some grey hair …
I hear what you’re saying and I don’t necessarily disagree … and the comparison with rules probably isn’t necessarily fair … just want to throw in that more intuitive and easier to think through is sometimes desirable above more functionality …
even though I tend to prefer the rynnignore file I think this here is pretty explicit and pretty easy to think along:
I guess the extension for attributes then would be:
[[rules]]
path = "*"
if = { extension = ".log", size_gt = "100MB" }
action = "ignore"
which then I think would lead to people hand-crafting ignore configs specifically for their setup/needs
with ignore files you tend to throw in default-configs with way too many entries …
edit/ps: actually if I can have an additional .rynn.toml in subfolders that can be cloned with projects so that I don’t need to maintain one big global config I’m now at the rules side
2 Likes