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

Rework Outgoing MessagePath #3356

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

volundmush
Copy link
Contributor

Brief overview of PR changes/additions

Added settings.SENDABLE_CLASS_MODULES for loading up (replaceable) Sendable classes from modules using callables_from_module. They're cached to evennia.SENDABLES (a dictionary)

Added evennia.server.sendables with some example Sendables.

Adds .send() method to Characters, Sessions, Accounts, Commands which handles the new outgoing path. This method takes a list of Sendable objects and a metadata dict to associate with the Sendables. Everything involved must be pickleable for this to work.

Altered the .msg() methods on Character, Sessions, Accounts, and Commands to convert their outgoing messages into a list of Sendables (the EvString placeholder and OOBFunc Sendable). These two ultimately are rendered exactly as existing Evennia messages are, for backwards compatibility.

Added a feature to AMP so it can actually send the Sendables. This process is actually a bit more efficient than the old way, since it can multi-cast the message to multiple sessids with a single AMP transmission.

Created a new PortalSession base class and made it customizable via class_from_module. It has methods to handle the Sendables.

Motivation for adding to Evennia

Well, just gotta read over issue #3354 to get the picture.

Other info (issues closed, discussion etc)

Well I haven't exactly rewritten all of the documents and some more documentation is probably needed.

Copy link
Member

@Griatch Griatch left a comment

Choose a reason for hiding this comment

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

I must say that this looks quite good overall. I appreciate your work on this. I have made many comments below; apart from minor things, like naming conventions and a few questions, we need extensive unit tests for this:

  • Unit tests for the new default sendable logics on the server side, including serialization/deserialization tests.
  • Unit tests for portal, making sure sendables output expected results (mocking out any AMP/wire calls, enough to test what is generated)
  • Full unit test suite for the new ansi-to-html (ravensgleanin.py) module.
  • Also, legacy unit tests are not passing as it is; that needs fixing too; to make it clear how backwards-compatible this is with the legacy message path.
  • Performance. We are still serializing to tuples across the AMP connection, so that should be fine - but is there any impact to serializing to/from a Sendable on each side? Would be good to have some comparisons or discussions around this.

Also, as a note (mainly to myself); if this merges; it will mean rewriting all documentation for the message path and how to extend these parts of Evennia.

Note to @volundmush Please don't rebase your fixes as you make them, since that loses the history and it becomes very hard for me to see what changes. The PR can be rebased once it's ready to merge, but then it's a good idea to add github comments to the code to make things a little easier to review 🙏

sendables, metadata = msg_to_sendables(**kwargs)
self.send(sendables, metadata=metadata, sessions=sessions)

def send(self, sendables: list["Any"], metadata: dict = None, **kwargs):
Copy link
Member

Choose a reason for hiding this comment

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

This needs a docstring on Google-style format, as for everywhere else in Evennia.

@@ -142,6 +142,14 @@ def data_to_portal(self, command, sessid, **kwargs):
self.errback, command.key
)

def data_multi_to_portal(self, command, sessions, data):
Copy link
Member

Choose a reason for hiding this comment

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

Looks like a docstring is needed here too, it's not clear how this differs from the data_to_portal command.

render_types = ("oob", "ansi", "html", "json")

@lazy_property
def ev_options(self):
Copy link
Member

Choose a reason for hiding this comment

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

Rather than ev_options, maybe session_options? Would also be good to have the docstring be a bit more informative about what this is.

load_kwargs={"category": "option"},
)

def sendables_out(self, sendables: list["Any"], metadata: dict):
Copy link
Member

Choose a reason for hiding this comment

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

Docstring. Not sure about the name of this. I presume this is akin to data_out?

"""
pass

def filter_sendables(self, sendables: list["Any"]) -> dict[str, list["Any"]]:
Copy link
Member

Choose a reason for hiding this comment

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

Docstring.

print(f"command: {command}")
if command:
parts = command.split(";")
print(f"parts: {parts}")
Copy link
Member

Choose a reason for hiding this comment

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

Another print

return self.html_for_state()


class RavensGleaning:
Copy link
Member

Choose a reason for hiding this comment

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

Needs to be renamed to something more informative. Also needs a docstring.

if not state.is_reset() or not mush_log:
ret += "</span>"

return ret
Copy link
Member

Choose a reason for hiding this comment

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

This module requires extensive unit tests.

@@ -3018,3 +3018,32 @@ def ip_from_request(request, exclude=None) -> str:

logger.log_warn("ip_from_request: No valid IP address found in request. Using remote_addr.")
return remote_addr


def split_oob(data) -> ["any", dict]:
Copy link
Member

Choose a reason for hiding this comment

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

Docstrings needed for everything here.



def split_oob(data) -> ["any", dict]:
if isinstance(data, (tuple, list)) and len(data) == 2:
Copy link
Member

Choose a reason for hiding this comment

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

The utils/utils.py is long enough as it is. Stuff in utils/utils.py should normally be things that people may want to grab and use elsewhere in their game, while this seems pretty specific to the message path. Maybe it would be better to have these utility functions in the evennia/server/ folder, like in a utils.py module, or as part of the relevant sendables.py etc.

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'm skeptical if server/utils.py is going to be any more informative than utils/utils.py when you get down to it...

@volundmush
Copy link
Contributor Author

Had to rebase due to merge conflicts.

@volundmush volundmush force-pushed the message_sendables branch 3 times, most recently from 9f0b859 to 78119df Compare December 17, 2023 08:38
@volundmush
Copy link
Contributor Author

Geeze this has come a long way.

@Griatch
Copy link
Member

Griatch commented Dec 19, 2023

Thanks for your work on this, @volundmush!
This will take a bit longer to review and and I think it needs to sit a bit in main before it goes into a release. So I'll review and hopefully merge this after I get Evennia 3.0 out.

@volundmush
Copy link
Contributor Author

I am starting to have second thoughts about the specific implementation of this. We should pow-wow and go over the details because yikes this is not something I want to screw up.

@Griatch
Copy link
Member

Griatch commented Jan 8, 2024

@volundmush Ok, I'm back now, so we can discuss. :)

@Griatch
Copy link
Member

Griatch commented Jan 14, 2024

@volundmush I know you had doubts about this implementation, but I still think this Sendables concept is better than passing JSON around :/

@Griatch
Copy link
Member

Griatch commented Jan 28, 2024

@volundmush So where are we on this one?

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

Successfully merging this pull request may close these issues.

None yet

2 participants