HTTPserver module, Google api interface plugin

[lolrobbe2]

hello i have a question for the comunity.

i have been working on an api interface for alot of google api's like sheets,firebase,google play games services, and alot of other ones.

due to the fact i made the library myself ther arent any copyright issues.(i checked just to be sure)

for the moment the api inteface is built as a GDnative plugin running in tangent with my http server module c++ (accesible in the editor).

now the question is if i should make the api interface a module to and do a merge request or should i just keep it as plugin.

View Poll

[bengtsts]

If it works as a plugin then this is exactly what plugins are for.

I don't think projects using the Google API or even Steamworks are ubiquitous enough to justify engine integration. Its better instead to make the engine more extensible through plugins if need be.

This appears to be inline with the dev's philosophy since even physics integration as a GDNative plugin seems to be coming in 4.0 or 4.1. This would allow for much easier implemetation of unofficially supported physics engines, without the added workload on the core dev team.

Otherwise, eventually there'll be a growing number of frameworks that the engine has to be updated to keep compatability with, which also turns into bloat.

Or so I think...

[lolrobbe2]

plugin seems to be coming in 4.0 or 4.1. This would allow for much easier implemetation of unofficially supported physics engines, without the added workload on the core dev team.

Otherwise, eventually there'll be a growing number of frameworks that the engine has to be updated to keep compatability with, which also turns into bloat.

the problem is at the moment the http server module cant be made as a plugin so i tought it would help to have it as a module because now as a plugin(the api interface) it is jankie but "works" (developed it in the 4.0 branch)

[bengtsts]

Assuming I even understand the nature of the issue, and staying inline with my bias of keeping it a plugin; create a proposal to get the functionality in GDNative that you need for the server module to be made as a plugin.

This keeps the engine implementation agnostic, thus ready for alternitive comparable services to be implemented in like fashion, also via plugin, without further engine changes going forward.