[vlc-devel] Regarding the HTTP POST implementation

Aniketh Girish anikethgireesh at gmail.com
Tue Oct 1 11:16:01 CEST 2019

On Fri, Sep 27, 2019 at 8:12 PM RĂ©mi Denis-Courmont <remi at remlab.net> wrote:

> Hi,

Hi Remi,

> First, I would *generally* advise against taking on bounties if you don't
> understand what it entails. The project is not short on bugs and bounties,
> if the goal is to fix one unparticular something...
> Now as regards HTTP POST, it's not a stand-alone thing, unlike most other
> bounties. Just like I'm currently working on an HTTP PUT access output to
> write PUT support, in the existing internal HTTP API, I don't think one can
> implement POST meaningfully and reasonably without a use case.
> So really, you first need to clarify what your use case(s) is/are.

Thanks for your response. Yes, you are right, one cannot implement
something meaningfully and reasonably without a use case. Without a
particular use case, I can implement this within 50 lines of code. But that
is not what we want in here, right? That is exactly why I'm asking the
reason for it being mentioned as a bounty in the first place. So let me
know what particular use case you have in mind so that let me also learn
more about it :).

Just another question that I had, why working on the implementation of
different HTTP methods differently? ie, why implementing PUT separately,
and POST separately? I think you want to stay with the idempotency of HTTP
methods? Rather than implementing various functions/callbacks for specific
HTTP methods, can't we implement code in a way that, (1) functionality that
supports idempotency of HTTP (GET etc) (2) a functionality that doesn't
support idempotency of HTTP (POST etc)?

Aniketh Girish
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> |
Website <http://aniketh01.github.io>

"For the Love of Code."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191001/2ce3e80f/attachment.html>

More information about the vlc-devel mailing list