Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81593
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CAH8MpnmumQFq8=JHQhq-uGe+dPW+jQDfR7O93xk1v=800ekRvw@mail.gmail.com>
References: <CAH8MpnktGy27BGFyH9i+tdfuMbti8KzHEXp=KD5LWy0vnKtxMw@mail.gmail.com>
	<CAPwsocELvXd+f2f_7-CeDB-=dQkM43yxZ5y3je8R9Tk8-0OYPw@mail.gmail.com>
	<CAH8MpnmumQFq8=JHQhq-uGe+dPW+jQDfR7O93xk1v=800ekRvw@mail.gmail.com>
Date: Mon, 2 Feb 2015 16:07:08 +0000
Message-ID: <CAEKnhAFwTOFY1q3iH=H9LJeFaDk4201gHOmGkps_BWDXQdHqfw@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@php.net>
Cc: Leigh <leight@gmail.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ed55a6be8cc050e1d25a9
Subject: Re: [PHP-DEV] Re: OpenSSL ext. improvements for authenticated cipher modes.
From: bukka@php.net (Jakub Zelenka)

--001a113ed55a6be8cc050e1d25a9
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 2, 2015 at 2:30 PM, Daniel Lowrey <rdlowrey@php.net> wrote:

> > The extra params aren't really _that_ bad.
>
> Okay, I'd like to reset the conversation a bit here. It's clear that the
> current API does not fit the problem domain very well. Tacking on more
> parameters only creates a bigger mess. Six parameters to a stateless
> function call is a completely incoherent API. It's unusable without
> consulting the manual. I think we need a completely different approach. Let
> me propose something else that won't break BC in any release and results in
> an API that's actually sane:
>
> class CryptoContext {
>     private $mode;
>     private $password;
>     function __construct($mode, $password) {
>         $this->mode = $mode;
>         $this->password = $password;
>     }
>     function encrypt($data) {
>         // ...
>         return $encryptedData;
>     }
>     function decrypt($data) {
>         // ...
>         return $decryptedData;
>     }
>     function setOption($option, $value) {
>         // ...
>     }
>     // more methods here to do anything you need
> }
>
> Thoughts on a stateful object API here? Personally I find this much more
> coherent than anything that's been proposed so far and it could be
> implemented without affecting existing functionality.
>

This is sort of what I was trying to do in crypto ext. I ended up with
something like this:
https://github.com/bukka/php-crypto#php-definition-for-the-classes which is
a bit simillar to your proposal and it already works as a bonus :). I'm not
sure if it makes sense to duplicate an effort and do the same thing (and
also call it Crypto which would be quite confusing...) in openssl ext which
is just functional extension. As I said the crypto extension is still in
pecl dev stability so I'm open any changes in it.

If we want to add a cipher context API to openssl ext, then I think that it
would be much better to use a functional API as openssl_pkey_* to keep ti
consistent.

Cheers

Jakub

--001a113ed55a6be8cc050e1d25a9--