Closed Xliff closed 4 months ago
I'd like a bit more info on the use case this tries to solve.
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).
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;
?
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.
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.
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.
Thank you @patrickbkr - Associative role removed.
Can't you just mix in a role at point?