Update Priority de/serialization

[yukibtc]

De/serialize Priority from/to string if the form is human-readable, otherwise to u8.

[yukibtc]

@JoeJoeTV

[yukibtc]

Seems that doesn't work anymore, probably the JSON payload must contain the priority as number.

[JoeJoeTV]

I also just checked, what is used for the JSON (de-)serializer:
The serde_json crate, which is used for this uses the default trait implementation for the is_human_readable function, which specifies that it is human readable, so If you're okay with it using a string for JSON, then this looks good to me.

[yukibtc]

The ntfy server return error 400 when sending the priority as string

[JoeJoeTV]

The ntfy server return error 400 when sending the priority as string

Yeah, the message format seems to specify an integer: https://docs.ntfy.sh/subscribe/api/#json-message-format

[JoeJoeTV]

Then maybe just allow strings in the deserializer, as I mentioned here and "force" u8 for serialization.

EDIT: I just realized that would still be a problem sometimes. Even if you won't keep the string in the (de-)serialization, having the as_str and from_str is still useful. I'll check how this works with serde attributes.

EDIT2: I also just remembered why this was a bigger problem. I have the Priorities in a hash map, so I can't directly use the attribute to specify a custom (de-)serialization function without replacing the one used for the hash map itself.

[yukibtc]

@JoeJoeTV, now the Priority support both deserialization from u8 and String

[JoeJoeTV]

@JoeJoeTV, now the Priority support both deserialization from u8 and String

Alright, thanks, nice, I'll try this with my usecase.

[JoeJoeTV]

@yukibtc This seems to work well! Thanks!

[yukibtc]

@JoeJoeTV I think we are ready for v0.7, right?

[JoeJoeTV]

Yes, I would say so.

[yukibtc]

@JoeJoeTV, I've just released v0.7