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

lua can not use request #377

Open
3125696610 opened this issue Dec 18, 2023 · 13 comments
Open

lua can not use request #377

3125696610 opened this issue Dec 18, 2023 · 13 comments

Comments

@3125696610
Copy link

我发现我不能直接用lua 调用pitaya的Request函数,因为它既是泛型函数,参数又是接口,c#无法制作扩展方法来给lua调用,这样子就限制了热跟新使用lua,作者可不可以为此做一些调整,谢谢
I found that I cannot directly call Pitaya's Request function with Lua because it is both a generic function, parameter, and interface. C # cannot create extension methods to call Lua, which limits the use of Lua. Can the author make some adjustments for this? Thank you

@felipejfc
Copy link
Contributor

What would be the change needed?

@3125696610
Copy link
Author

我希望unity 工程里面可以支持request请求传递jsonObject作为message,而不是固定的protobuf转的c#类作为参数,或者可以提供一个jsonObject转成Imessage的中间处理,就像pomelo这个插件一样,不过这个插件通讯太慢,希望pitaya能取长补短
我希望unity 工程里面可以支持request请求传递jsonObject作为message,而不是固定的protobuf转的c#类作为参数,或者可以提供一个jsonObject转成Imessage的中间处理,就像pomelo这个插件一样,不过这个插件通讯太慢,希望pitaya能取长补短
I hope that the Unity project can support the request request to pass jsonObject as a message, instead of using a fixed protobuf converted C # class as a parameter, or provide an intermediate processing for converting jsonObject to Imessage, just like the Pomelo plugin. However, this plugin is too slow to communicate, and I hope Pitaya can learn from its strengths and make up for its shortcomings

@3125696610
Copy link
Author

In this way, I can build a generic method in Unity that allows Lua to access C # by creating classes that can inherit from jsonObject, so that Lua can call the Pitaya plugin to implement network requests

@bruce1125
Copy link
Contributor

Pitaya supports json serializer by default, is that OK?

@3125696610
Copy link
Author

Should we default to supporting JSON serialization programs now or provide them in the future

@3125696610
Copy link
Author

If we can provide default support for JSON, then Pitaya is really perfect

@bruce1125
Copy link
Contributor

you could take a look at the source code where the path is : pitaya/serialize/json/json.go

If we can provide default support for JSON, then Pitaya is really perfect

@3125696610
Copy link
Author

1702978037192_0682B033-EF2F-4457-8EA9-DD2AC1D0EB4F
I'm not sure if there's an issue with my description. Let me rephrase where I need help because the Pitaya Unity plugin only provides access in the form of proto. I need to use JsonObject to access the network in the Unity plugin provided by Pitaya. Can you help me with this

@3125696610
Copy link
Author

As shown in the above figure, the Unity plugin provided by Pitaya can only access network functions with IMessage as a parameter. I hope the official can help extend it so that I can use JsonObject's parameters to access Request

@bruce1125
Copy link
Contributor

I see, dose the string reload version can work?
For me, I don't use the client sdk at all, so I'm not very familier with it, may be you can implement it by yourself?

@3125696610
Copy link
Author

I think I should be able to, but I want to know if using string transmission would result in a much larger network transmission byte count than using IMessage, which could affect the speed of data transmission and reception

@bruce1125
Copy link
Contributor

that is a significant issue between performance and api convenience, only yourself could balance them

@owllyi
Copy link

owllyi commented Dec 20, 2023

I manually wrapped the Request interface, converting it directly from Lua to the protobuf binary format. Some modifications were also made to the underlying pitaya library to adapt to this. The C# layer does not concern itself with or parse protobuf at all.

public bool Request(string route, byte[] buffer, Action<byte[]> action)

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

No branches or pull requests

4 participants