6 ms·

Configuration for this, especially the hook rules definitions, would be better in some DSL rather than JSON. Trying to structure logic as JSON is very hard to r

by neuland 10y ago

Configuration for this, especially the hook rules definitions, would be better in some DSL rather than JSON. Trying to structure logic as JSON is very hard to read. Edit: if you aren't married to configuration in a file, you could even do hosted JS or Lua functions kinda like a serverless environment

lygaret 10y ago
Hell, just hson or yaml...
gbaygon 10y ago
I think that using some DSL rather that JSON will make it more obscure, since a lot more people are familiar with JSON coming from front-end development and/or Node. If you want a big userbase and more potential contributors is good to stick to what everybody is using. (Reading my own answer I would be swearing at anyone that told me that about an XML config file a couple of years ago) Edit: redaction
- masukomi 10y ago
  for the others who don't know the history.... (despite your added comment) You can take what you've said, replace "JSON" with "XML" and you've got an explanation for Maven and all the other Java tools with a ridiculous amount of logic shoved into some generic markup format that was never intended for it. History has shown that it sucks to deal with. XML was the hot, "obvious", "everybody knows it", format of its day. I agree that JSON is, in most uses, a hell of a lot better, but, like XML it is a terrible place to be defining logic. It really needs to be something that is actually designed to encode logic, not a data structure format. A custom DSL is a decent, and probably very easy (for users) idea, but if the author was really not interested in the design and debugging of such a thing then you could use LUA or some other embedded language.
  - neuland 10y ago
    You explained this way better than I did. It's not the configuration that I had issues with. Rather, it's the triggers/rules. I think I even mentioned embedded JS or Lua in some other comment.
adnanh 10y ago
I agree, the biggest pain point I've identified in my tool is the actual configuration. It's okay for simple definitions, but as the number of endpoints grow, it becomes messy. I started work on a CLI tool that would be responsible for managing the hooks.json file, but I haven't had enough time to devote to it. (My wife, my daughter and my daily job currently occupy most of my time...)
- neuland 10y ago
  The only part that made me comment was the rules definitions. I will gladly write key/value type config in JSON or YAML or whatever. But, writing the rules logic in it would be a big pain, because it is not easy to see what deeply nested and and or statements mean. JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good. I've had a couple of projects recently where I was writing a parser. And, there is a lot of tooling to make it easier: lex/flex, yacc/bison, PEG-style tools like Python's Parsimonious [0]. (I'm sure there are similar libraries in JavaScript) Defining the grammar is a bit arcane, but the only other thing you write is the interpreter, which you already have a version of (just with a different AST format). In any case, the project/service is really cool! [0] https://github.com/erikrose/parsimonious https://github.com/erikrose/parsimonious
- neuland 10y ago
  The only part that made me comment was the rules definitions. I will gladly write key/value type config in JSON or YAML or whatever. But, writing the rules logic in it would be a big pain, because it is not easy to see what deeply nested and and or statements mean. JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good. I've had a couple of projects recently where I was writing a parser. And, there is a lot of tooling to make it easier: lex/flex, yacc/bison, PEG-style tools like Python's Parsimonious [0]. (I'm sure there are similar libraries in JavaScript) Defining the grammar is a bit arcane, but the only other thing you write is the interpreter, which you already have a version of (just with a different AST format). In any case, the project/service is really cool! [0] https://github.com/erikrose/parsimonious https://github.com/erikrose/parsimonious

by neuland 10y ago

lygaret 10y ago

Hell, just hson or yaml...

gbaygon 10y ago

I think that using some DSL rather that JSON will make it more obscure, since a lot more people are familiar with JSON coming from front-end development and/or Node. If you want a big userbase and more potential contributors is good to stick to what everybody is using. (Reading my own answer I would be swearing at anyone that told me that about an XML config file a couple of years ago) Edit: redaction

masukomi 10y ago
for the others who don't know the history.... (despite your added comment) You can take what you've said, replace "JSON" with "XML" and you've got an explanation for Maven and all the other Java tools with a ridiculous amount of logic shoved into some generic markup format that was never intended for it. History has shown that it sucks to deal with. XML was the hot, "obvious", "everybody knows it", format of its day. I agree that JSON is, in most uses, a hell of a lot better, but, like XML it is a terrible place to be defining logic. It really needs to be something that is actually designed to encode logic, not a data structure format. A custom DSL is a decent, and probably very easy (for users) idea, but if the author was really not interested in the design and debugging of such a thing then you could use LUA or some other embedded language.
- neuland 10y ago
  You explained this way better than I did. It's not the configuration that I had issues with. Rather, it's the triggers/rules. I think I even mentioned embedded JS or Lua in some other comment.

adnanh 10y ago

I agree, the biggest pain point I've identified in my tool is the actual configuration. It's okay for simple definitions, but as the number of endpoints grow, it becomes messy. I started work on a CLI tool that would be responsible for managing the hooks.json file, but I haven't had enough time to devote to it. (My wife, my daughter and my daily job currently occupy most of my time...)

neuland 10y ago
The only part that made me comment was the rules definitions. I will gladly write key/value type config in JSON or YAML or whatever. But, writing the rules logic in it would be a big pain, because it is not easy to see what deeply nested and and or statements mean. JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good. I've had a couple of projects recently where I was writing a parser. And, there is a lot of tooling to make it easier: lex/flex, yacc/bison, PEG-style tools like Python's Parsimonious [0]. (I'm sure there are similar libraries in JavaScript) Defining the grammar is a bit arcane, but the only other thing you write is the interpreter, which you already have a version of (just with a different AST format). In any case, the project/service is really cool! [0] https://github.com/erikrose/parsimonious https://github.com/erikrose/parsimonious
neuland 10y ago
The only part that made me comment was the rules definitions. I will gladly write key/value type config in JSON or YAML or whatever. But, writing the rules logic in it would be a big pain, because it is not easy to see what deeply nested and and or statements mean. JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good. I've had a couple of projects recently where I was writing a parser. And, there is a lot of tooling to make it easier: lex/flex, yacc/bison, PEG-style tools like Python's Parsimonious [0]. (I'm sure there are similar libraries in JavaScript) Defining the grammar is a bit arcane, but the only other thing you write is the interpreter, which you already have a version of (just with a different AST format). In any case, the project/service is really cool! [0] https://github.com/erikrose/parsimonious https://github.com/erikrose/parsimonious