run_in_thread decorator for multi-user views

[fscherf]

Hi!
When writing multi-user views, LonaView.iter_objects() is used to interact between multiple objects of the same view.

class MultiUserView(LonaView):
    def send_message(self, message):
        for view in self.itter_objects():
            view.messages.append(messag)

    def handle_request(self, request):
        self.messages = Pre()

        self.html = HTML(
            H1('Multi User View'),
            messages,
            Button('Stop')
        )

        self.send_message(f'{datetime.now()}: New view started')

        self.show(self.html)

        self.await_click()

        self.send_message(f'{datetime.now()}: View stopped')

This code works fine as long as send_message returns fast. If this funtion would do something long running handle_request() would have to wait til all views have sent the message.

You can fix this if you use server.run_function_async(). I propose a decorator named @run_in_thread that can be added to all methods of a view, besides the buildin ones (handle_request, handle_input_event, etc).

If a function decorated like that, gets called, the call directly returns a concurrent future, which can be awaited using future.result() if needed. For messaging like in this view, you would just fire and forget.

@maratori, @laundmo, @TheMutt, @sobolevn, @korantu: Thoughts?

[maratori]

I've started using lona to create multiplayer card game.
Now there is the only way for views to communicate - when one view executes a method of different view.
Personally I don't like this pattern. I think it goes against object thinking.

What about having some channel for different views to communicate (a)synchronously?

We already have InputEvent. Let's add new ServerEvent (need to find better name).
View can send this event to another view (or to itself as well). Another view can handle this event and do whatever is necessary.

class MultiUserView(LonaView):
    def send_message(self, message):
        self.fire_server_event(data=message, broadcast=True, wait=False)

    def handle_server_event(self, event):
        self.messages.append(event.data)
        self.show()

[fscherf]

@maratori Yes i am not happy with this pattern either. I was not sure how to implement this properly, and for that time being i only needed single-user views and sometimes daemonized views. So i made all objects, of a view class, available to the application code. My thought process was that, if you need messaging between objects, you can implement it yourself.

When a coworker of mine and i brainstormed this topic, we thought of something very similar to Your example.
The open questions were:

• Should a middleware get these events to handle too? (i think it should)
• How would handle_server_event() interact with handle_request()?
  • In handle_request() you can run await_input_event(); Do we add an equivalent to this? How can i wait on multiple events (click and server_event)
• What are the parts of such an event?
  • A string as name and a dict as payload?

Event vs Message
I am not completely sure if we should implement events here. Lona's concept of events is a chain of event handler in which every handler can stop an event from bubbling up further.
I think we should name this call LonaView.send_message(data=message, broadcast=True, wait=False)

[maratori]

Should a middleware get these events to handle too?

I'd say no. I can't imagine an example where is would be necessary. Do you?
I thought that middleware is about communication with browser, not between different parts of the server.

In handle_request() you can run await_input_event(); Do we add an equivalent to this? How can i wait on multiple events (click and server_event)

First of all I think await_input_event() is useful in very limited number of cases. And they are very basic ones (correct me if I'm wrong).
From the other side server event is something advanced. So I'd say we should not create equivalent.

But we can easily do it, if want. We can add following methods:

• await_server_event(...) -> ServerEvent
• await_event(...) -> Union[InputEvent, ServerEvent]

What are the parts of such an event? A string as name and a dict as payload?

That depends. Will different views always be executed in the same python process? Or will we use multiprocessing or even deploy to several kubernetes pods?

If the same process, we can use following fields:

• name: str - user defined
• payload: Any - user defined
• producer: LonaView - added automatically by lona

If not, then we should use only basic types to be able convert it to json.

• name: str
• payload: Union[int, float, str, bool, list[X], dict[str, X]], where X is the same union.
• producer_class_name: str

Event vs Message

I don't mind to call it message or somehow else. I just wanted to demonstrate concept.

I think we should name this call LonaView.send_message(data=message, broadcast=True, wait=False)

I thought about send_message(), but it is not clear what means "send". To browser or to another view?
Also it may be confusing to see send_message() next to send_str(). What is the difference?

[fscherf]

Should a middleware get these events to handle too?

I'd say no. I can't imagine an example where is would be necessary. Do you?
I thought that middleware is about communication with browser, not between different parts of the server.

Not only. The middleware system is meant to contain all sorts of hooks, where the server gives the application opportunity to change the built in behavior. Thats why on_startup and on_shutdown are part of the middleware system. They can be used as simple plugins if you will. In this case i would use a middleware hook to distribute events to other processes or machines.

In handle_request() you can run await_input_event(); Do we add an equivalent to this? How can i wait on multiple events (click and server_event)

First of all I think await_input_event() is useful in very limited number of cases. And they are very basic ones (correct me if I'm wrong).
From the other side server event is something advanced. So I'd say we should not create equivalent.

await_input_event() and its helper methods like handle_click() are only for interactive wizards useful. For cases where the view does not know how to continue, or needs confirmation. These use cases are a real pain with callback logic. For every other form of input event, for example a table with n buttons like in https://lona-web.org/demos/bootstrap-5-confirmation-popup/index.html these methods are the wrong tool.

So an equivalent would only make sense if there was a reason why a view should stop and wait for another view to send a message.

What are the parts of such an event? A string as name and a dict as payload?

That depends. Will different views always be executed in the same python process? Or will we use multiprocessing or even deploy to several kubernetes pods?

Currently Lona has no model for multiprocessing. When i use Lona with multiple processes, i create a systemd template unit, and start my project multiple times on different ports. Then i use the apache2 load balance feature with sticky sessions in front of my Lona processes. To connect the different processes i let them use the same database or connect them all to the same message queue. To do so i create a simple middleware that implements an on_startup() method, that connects to the message queue and waits for messages. If one is incoming, i use server.get_view_class() to get the correct view class to pass the message further.

I thought about send_message(), but it is not clear what means "send". To browser or to another view?
Also it may be confusing to see send_message() next to send_str(). What is the difference?

I agree. But i am not sure if i want to call them event because you could think that they should behave like input_events but they will have to behave very differently.

[grigolet]

I find both the @run_in_thread and the event based proposal very appealing for multiuser/broadcasting applications. From one side I like the idea of having the views object available to use as I can build custom filters on the views I want to modify; from the other side I find the event based system easier to read and to write 🤔
Would having both features be in conflict with each other?

[maratori]

Just wanted to note that you can use custom filter with events as well.
Following example will send an event to all other views except itself.

def send_message(self, message):
    self.fire_server_event(data=message, broadcast=True, filter=lambda view: view is not self, wait=False)

[fscherf]

@TheMutt LonaViews.iter_objects() is here to stay i think. Even if this is not the go-to call to implement messaging anymore, it's a very powerful feature. @run_in_thread may be not required anymore for messaging ,when we come up with a better solution, but since the server class already has this functionality, it could be a useful little helper.

@maratori filter is a good idea, and is consistent with ``LonaView.send_str()`

[fscherf]

@maratori, @TheMutt: I started implementing server.fire_view_event(name: str, data: dict) I am not settled on the name, but while implementing it made more sense to me because these events get handled by views. The view hook is called on_view_event().

While implementing I noticed something: When a views handle_request() waits on an input event by using await_click() its stuck until an event is incoming or the view is stopped. So its not possible to fire an event to tell all views to do something else if they wait for an input event.

We could add a call to discard all pending input events, or build a combined call like await_event().

Edit: I pushed the current state of my patches to https://github.com/lona-web-org/lona/tree/fscherf/multi-user

[maratori]

So its not possible to fire an event to tell all views to do something else if they wait for an input event.

I'm not an expert in asyncio. Can you explain why?

We could add a call to discard all pending input events, or build a combined call like await_event().

How await_event() helps? It will still stuck if await_click() is called in handle_request()?

[grigolet]

I also didn't understand how await_event() could help. When you say build a combined call do you mean a general call that does not differentiate between inputs and views events?

[fscherf]

I am sorry, let me explain this in more detailed.

Let's say i want to build a chat application where are normal users and admins. The chat interface for normal users has an TextArea and a send button, and the view waits with await_click() that the send button gets clicked. The admin view has a kick button, to kick users from the chat.

When the admin clicks "kick", the user still has to click "send" to unblock the main thread of his view. Currently we can not cancel an await (that's no asyncio problem, that's (maybe) a Lona API flaw). If we had await_event() which can return a view event or an input event, that would be no problem.

I am not completely sure yet if this is a problem at all. Since we have callbacks in all nodes we essentially can await multiple events at once, so there is certainly a way around this problem.

[maratori]

@fscherf I've reproduced your scenario in this branch (Multi User Chat in test_project).
It works like charm. The only issue is that method handle_request never stops. But it's not a problem of lona, IMHO.

For example the same happens if I await_click(hidden_node). Developer of this view should foresee such scenarios.

About await_event. Yes we can add it as well, like I mentioned earlier. But I don't think we should.

[fscherf]

@maratori Thanks! I think you are right. In this case i think we don't need await_event() (at least for now). I have some finishing touches on my branch to do, then i will create a pull-request

[fscherf]

FTR: View events are implemented now