AlliedModders

AlliedModders (https://forums.alliedmods.net/index.php)
-   New Plugin Submissions (https://forums.alliedmods.net/forumdisplay.php?f=26)
-   -   HTTP:X (https://forums.alliedmods.net/showthread.php?t=282949)

Black Rose 05-21-2016 12:37

HTTP:X
 
11 Attachment(s)
HTTP:X

This plugin is an API to download files and web content to the server and/or send commands using the HTTP protocol through other plugins.
It is not used to send files to clients. That is impossible.

This plugin will always keep itself up to date by automatically downloading the latest version whenever a new one is available.
This means that you as a developer can be relatively sure that the client has the correct version if your plugin requires possibly new functions.
This can be disabled by cvar.

You can also use this plugin to update your own plugin automatically. I suggest adding a version check first. Examples can be found below.
Remember that floats in PAWN are not 100% accurate so integers or strings should be used for checking if there is a new version available.
Also remember that for your plugin to be updated (downloaded) it has to compile without custom includes on this site. So any external functions has to be included inside the source of your plugin.
This can also be disabled by cvar.

Examples


httpx.inc


Changelog


Additional notes:
I'm always open to suggestions, feedback and criticism. Please share your thoughts.

EFFx 05-21-2016 13:34

Re: HTTP:X
 
How i spoke

You're not human
You're a E.T
You're awesome

GordonFreeman (RU) 05-22-2016 05:01

Re: HTTP:X
 
Thanks. Its very useful for working with json api.

klippy 05-22-2016 08:02

Re: HTTP:X
 
Didn't really look through your code thoroughly, but I noticed something. Why do you use callfunc_* natives in your auto-updater? Fake natives were made to avoid that, I believe, and it would make it simpler and easier to remember.

Also, here's something interesting you might want to take a look at: https://github.com/rsKliPPy/webserver_amxx. You could look at it as a server for the client you just wrote here, so it would allow cross-server communication with HTTP, almost like JS/AJAX. I was just too lazy past couple of months to add some finishing touches and release it. :/ Tell me what do you think about it.

Great job overall!

Black Rose 05-22-2016 12:40

Re: HTTP:X
 
I use callfunc_* because it doesn't make a plugin fail if the function doesn't exist.
That way, people can build autoupdate into their plugins but not make HTTP:X a requirement for it to run, just an option.

Honestly, I don't understand what the webserver is for.
Communication plugins are already out there with less overhead and more flexibility. This was not made to compete with them.

klippy 05-22-2016 13:44

Re: HTTP:X
 
There is set_module_filter() if the API user decides he wants it optional when using natives.
Even if you want it to stay that way, you should wrap it into a stock functions in your include file. Along the lines of:
PHP Code:

stock HTTPX_AutoupdatePlugin(const file_id[], frequency) {
    if ( 
callfunc_begin("AutoupdatePlugin""httpx.amxx") == ) {
        
callfunc_push_int(get_plugin(-1));
        
callfunc_push_str(file_idfalse);
        
callfunc_push_int(frequency);
        
callfunc_end();
    }


and callfunc might be also bad for a reason that it relies on plugin name, that is "httpx.amxx". That's pretty hardcoded in my opinion.


I know this may be going a bit offtopic, but the webserver is basically a module for hosting a HTTP server on top of a HL server. It's a GoldSrc/HL counterpart of Asherkin's HTTP server. It lets one program dynamic web pages with Pawn, just like you would do with PHP for example. Just a fun project and I brought that up as your plugin revolves around HTTP.
Cross-server communication was just an example what those two could do if they got their powers combined.

Black Rose 05-22-2016 18:08

Re: HTTP:X
 
If a plugin was using the include there would be no point of autoupdating since it wouldn't pass the compiler. This is done intentionally.
I don't see how set_module_filter() would help in this case. I have never used that function and I'm having a hard time understanding what it actually does. If you can show me what your thoughts were I would appreciate it.

The hardcoded part I could edit easily. I'll do that tomorrow. Done
Thank you for your feedback.

I'm not very experienced in C(#/++). But as far as I can tell your HTTP server looks professional.

klippy 05-22-2016 19:03

Re: HTTP:X
 
Quote:

Originally Posted by Black Rose (Post 2421251)
If a plugin was using the include there would be no point of autoupdating since it wouldn't pass the compiler. This is done intentionally.
I don't see how set_module_filter() would help in this case. I have never used that function and I'm having a hard time understanding what it actually does. If you can show me what your thoughts were I would appreciate it.

Oh, I totally misunderstood how the plugin updater works. I just saw that it actually downloads files from the web compiler, that wasn't obvious at first. Now I see why you used callfunc instead of creating a native, that explains it.
But here's the question then - what if a plugin includes a non-standard include file? Just like your own? That could be solved by copying include file's contents onto the top of the code, but that's not really the solution.

Quote:

Originally Posted by Black Rose (Post 2421251)
Thank you for your feedback.

Anytime. I really like this plugin/API and I am happy to help at improving it.

Black Rose 05-23-2016 13:24

Re: HTTP:X
 
It depends on the include. Some things are just stupid to move into an include. ColorChat is a great example. One small, simple function that comes in too many different versions.
If people copied the code instead they would compile fine online and it wouldn't be so hard to find the right version of colorchat.

It got me thinking and I'm gonna create an add-on that will update plugins instead. I think that will be easier for everyone. But that still won't work with custom includes.

This can be solved by using another compiler with the proper includes but I will not use anything else than downloads from AM. Mainly because malicious code is rare and will be removed but also for the sake of the GPL being enforced here.

Shooting King 05-26-2016 15:19

Re: HTTP:X
 
Why don't you make a Multi-threaded solution too instead of entity thinks ? ThreadedSocks


All times are GMT -4. The time now is 21:10.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.