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

add support for extended addressing (xep-0033) #185

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bartekgorny
Copy link
Contributor

You may want to add some syntactic sugar, depends on your taste - for now the interface is a bit raw, you have to pass a tuple containing multicast host and a list of #extaddress{} records.

@@ -27,3 +27,11 @@
event_client :: any(),
props :: list()
}).

-record(extaddress, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm limited or sth but I think that using a map here would simplify developer's life when it comes to debugging (which is quite common part of our day to day life :) ). The map could have it's own type with required and optional type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have nothing against maps, they are so useful when you need flexibility. But when I know for sure what the data structure is supposed to contain I prefer records, they make code so much more readable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

they make code so much more readable

I'd say the same about maps :) plus they make debugging so much nicer :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do they give you code completion?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I don't use code completion so I don't care :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case is not a big deal, so if it is your strict requirement then fine, I can change it to a map. But, really, we should give it a serious though. From what I know, our coding guidelines do not say "never use records", but the practice seems to be heading in that direction. I'd suggest we make some effort to formulate a common approach, stating which data structure should/can be applied in which cases, to avoid such tensions in the future.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a strict requirement, note that I didn't request for changes, just commented in the review :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, got it. Can it be merged, then?

@michalwski
Copy link
Contributor

Did you try it with current MongooseIM tests? escalus_stanza:message/4 was modified, there is a good chance this function is used somewhere in big_tests. It be good to know that tests still work with your changes.

Please rebase this branch on top of current master (there was quite many changes in escalus recently) and open a PR in MongooseIM with escalus from this branch.

@NelsonVides
Copy link
Contributor

Reviving this one, old and with some conflicts by now but I like the idea, would be cool to implement so in MongooseIM as well so having the testing tool will be useful beforehand. Any thoughts on this? @bartekgorny

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants