You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the README for bert.erl specifies that the module user must encode their own date and regexes, but doesn't provide functions to implement the spec for this.
It'd be really handy if a couple of utility functions were included in the bert module for doing this, and maybe even if there was a way to actually tag an already-encoded date or regex so that bert:encode/1 doesn't double-encode it. Maybe simply skipping any tuple that looks like a BERT-encoded time or regex?
I'm not totally sure about this last part, as it seems there's a risk of failing to encode a tuple that happens to look like a date {bert, date, int(), int(), int() } or regex, but I guess that's uncommon enough to not be a problem, given I see no countermeasures against the inverse problem on the decoding side.
The text was updated successfully, but these errors were encountered:
Huh, I just noticed that bert:decode_term/1 doesn't decode regexes or times either. So maybe that should be supported? Depends on the rationale for not having that support in bert:decode_term/1 already.
Currently the README for bert.erl specifies that the module user must encode their own date and regexes, but doesn't provide functions to implement the spec for this.
It'd be really handy if a couple of utility functions were included in the bert module for doing this, and maybe even if there was a way to actually tag an already-encoded date or regex so that bert:encode/1 doesn't double-encode it. Maybe simply skipping any tuple that looks like a BERT-encoded time or regex?
I'm not totally sure about this last part, as it seems there's a risk of failing to encode a tuple that happens to look like a date {bert, date, int(), int(), int() } or regex, but I guess that's uncommon enough to not be a problem, given I see no countermeasures against the inverse problem on the decoding side.
The text was updated successfully, but these errors were encountered: