[vlc-devel] Regarding the HTTP POST implementation
anikethgireesh at gmail.com
Sun Oct 6 17:20:53 CEST 2019
> AFAIR, some devs wanted POST for some use cases, but I cannot comment on
But if you wish to share what think off, I am more than happy to listen to
> There is currently one POST usage in the audioscrobbler module.
I see that. Get's the payload and does a TLS_write()..
> > Just another question that I had, why working on the implementation of
> > different HTTP methods differently?
> Useful APIs are rather different for GET than POST.
> > ie, why implementing PUT separately, and POST separately?
> PUT is used to write a file over the network.
> POST is more of a toolkit for request/response messaging.
> The usage patterns and thus the API designs would be quite different.
I understand. But don't you think the HTTP functionalities should be
implemented as it is standardised to and change the way we use it rather
than developing HTTP functionalities for some specific use cases? What I
meant is that, design the HTTP API as meant, that is, GET gets us
something, POST sends over something etc. Thus, all the HTTP functions does
what it is supposed to do and the modules that use these methods should
design their callbacks and functions in a way that they can incorporate the
use cases within the module itself. Also, doing a TLS_write() to suggest
HTTPS send a request with or without payload seems confusing too. But what
I suggest is an API, like http_send_req(conn, req, body, bool TLS). With
that bool, we can turn on and off the TLS option??
Because I feel this way, we will never stop refactoring core design of HTTP
every time. I see there is already an old HTTP access and a new
What do you think? I have a small design document as well for this:
Member at FOSS at Amrita <http://foss.amrita.ac.in/>
Amrita University <http://amrita.edu>
<https://github.com/Aniketh01>Github <https://github.com/Aniketh01> | GitLab
<https://gitlab.com/Aniketh01/> | Blog <http://anikethfoss.wordpress.com> |
"For the Love of Code."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel