Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format for lists and dictionary responses #615

Open
SamMousa opened this issue Jan 4, 2022 · 3 comments
Open

Format for lists and dictionary responses #615

SamMousa opened this issue Jan 4, 2022 · 3 comments
Labels
FeatureRequest Unplanned Issue is not planned for some reason, such as complexity, lack of clarity, or low priority.

Comments

@SamMousa
Copy link
Contributor

SamMousa commented Jan 4, 2022

I think a somewhat simpler/easier way forward would be to restrict the output format of the existing commands from YAML to JSON. This ought to be a backwards-compatible change, since all YAML parsers are supposed to be able to read JSON. However, it would be worth testing the major client languages to double-check that they actually do the right thing in that case.

Originally posted by @kr in #610 (comment)

I've thought some more on this and I think going either the YAML or the JSON road is troublesome unless you want to pull in a proper library into beanstalkd.

We could actually simplify the formats as well, since the beanstalkd protocol is a text based protocol and requires a custom parser / interpreter it's not much work to define the lists and dictionaries.

Lists:

  • All entries are strings
  • Each entry is separate by a \n

This gives you all you need to know, no parsing and more importantly no escaping required.

Dictionary:

  • Each entry has a key and a value
  • Since we control the keys we can just put strict definitions on them; keys only consist of the alphabet a-z and the character -.
  • Values should be interpreted as string unless we specify that they are some other type explicitly.
  • Keys and values are separated by a :

These could have trivial implementations in beanstalkd code and to not break existing clients we could implement these as new commands. For example stats-tubes-2 or stats-2.

For me this has no priority by the way, I'm happy parsing the YAML in it's current state and since I'm assuming developers create tube names in a reasonable way (not containing user input) it should cause no issues.

@kr
Copy link
Member

kr commented Jan 4, 2022

Good points! I agree.

@kr kr added FeatureRequest Unplanned Issue is not planned for some reason, such as complexity, lack of clarity, or low priority. labels Jan 4, 2022
@SamMousa
Copy link
Contributor Author

Would you accept a contribution that implements this as new commands (to not break backwards compatibility)?

At the same time we could then deprecate the old commands.

@kr
Copy link
Member

kr commented Jun 2, 2022

In principle yes, but in practice I probably don't have time to review the code.

If any other maintainer wants to review, go for it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest Unplanned Issue is not planned for some reason, such as complexity, lack of clarity, or low priority.
Projects
None yet
Development

No branches or pull requests

2 participants