- Adds ability to associate arbitrary data with a Cro::Message

[Xliff]

No description provided.

[lizmat]

Is this necessary?

[Xliff]

Yes. It's the easiest way to implement what I need.

[lizmat]

Why not has %!attributes handles <keys pairs values AT-KEY EXISTS-KEY> and possibly extend on that when needed?

[Xliff]

That should work.

[vendethiel]

Can't you just mix in a role at point?

[patrickbkr]

I'd like a bit more info on the use case this tries to solve.

[Xliff]

A role? No.

The point is that... as far as a Cro::Message goes, there is ONLY the payload. There isn't any way to determine routing information. I can't tell where the Message came from or where it is going to!

Consider: Any use case that isn't a microservices server that use TCP as a transport mechanism.

To make things worse, Cro::Message doesn't even allow you to look at the TCP data to get said routing information.

And what if the routing needs go beyond TCP?

So in this situation, I decided to make Cro::Message capable of handling any set of OOB information (OOB = anything outside of the message payload).

[patrickbkr]

In the case of Cro::HTTP Cro::Message is inherited into Cro::HTTP::Message adding fields as necessary. Wouldn't the same also work for your use case?

Should we decide this is a good idea, I would like to not have Cro::Message act as an Associative. It's a pretty arbitrary decision that user defined data should be accessible via the Associative interface while other mappy bits (like headers or cookies in an HTTP::Message) are accessed using attributes. This creates confusion. Can we instead just have has %.attributes;?

[patrickbkr]

In Cro-FCGI I subclassed Cro::HTTP::Request adding a few FCGI specific fields and have the Cro::FCGI::RequestParser emit objects of that type. That worked for my use case.

[Xliff]

I'm OK with dropping the Associative interface, but I do need out of band data in a Cro::Message subclass.

UPDATE - After looking at Cro::HTTP::Message, I am still of the opinion that Cro::Message is the best place for this. Remember, Cro::HTTP::Message is for HTTP traffic. I need a generic solution that does not tie itself to any specific transport.

Why is there a problem with putting %.attributes on Cro::Message?

Also, I am not OK with making this a subclass. This is something I feel is missing from Cro::Message, and I have yet to hear a good reason as to why it shouldn't be there.

Thanks for listening.

[patrickbkr]

I don't have a big issue with that attribute. It's just that adding public interfaces is a lot easier than removing them. And as I don't have a good intuition about the Cro APIs yet, I'm a bit cautious to add public interfaces especially in the lower layers. That's all.

So given we get rid of Associative, I'm ok with merging this.

[Xliff]

Thank you @patrickbkr - Associative role removed.