Compression.Lz4

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Compression.Lz4

Stephen R. van den Berg
For the new CQL driver I need Lz4 support.
Now, instead of introducing yet another toplevel Lz4 object, how about
moving Bz2 and Gz and Lz4 into:

Compression.Bz2
Compression.Gz
Compression.Lz4

Any objections?
--
Stephen.  
Reply | Threaded
Open this post in threaded view
|

Compression.Lz4

Martin Nilsson (Coppermist) @ Pike (-) developers forum
>For the new CQL driver I need Lz4 support.
>Now, instead of introducing yet another toplevel Lz4 object, how about
>moving Bz2 and Gz and Lz4 into:
>
>Compression.Bz2
>Compression.Gz
>Compression.Lz4
>

If we change location I want them to have the same API so you can
switch between them easily. Old locations should have compatibility
wrappers of course.
Reply | Threaded
Open this post in threaded view
|

Re: Compression.Lz4

Stephen R. van den Berg
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>Compression.Bz2
>>Compression.Gz
>>Compression.Lz4

>If we change location I want them to have the same API so you can
>switch between them easily. Old locations should have compatibility
>wrappers of course.

Same API, of course.
Compatibility wrappers, well, since it's the same API, the migration is easy.
So if you call up pike in compatibility mode (8.0 and older), it should have
the wrappers.
But in 8.1+ mode, I could imagine omitting the compatibility wrappers from
the getgo.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Re: Compression.Lz4

Chris Angelico
On Thu, Apr 1, 2021 at 6:18 PM Stephen R. van den Berg <[hidden email]> wrote:

>
> Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
> >>Compression.Bz2
> >>Compression.Gz
> >>Compression.Lz4
>
> >If we change location I want them to have the same API so you can
> >switch between them easily. Old locations should have compatibility
> >wrappers of course.
>
> Same API, of course.
> Compatibility wrappers, well, since it's the same API, the migration is easy.
> So if you call up pike in compatibility mode (8.0 and older), it should have
> the wrappers.
> But in 8.1+ mode, I could imagine omitting the compatibility wrappers from
> the getgo.

I'd prefer the wrappers, since it makes porting a lot easier. I
generally prefer to be able to run without compatibility mode, and
then have fallbacks in my code where there are actual differences.

ChrisA
Reply | Threaded
Open this post in threaded view
|

Re: Compression.Lz4

Tobias S. Josefowitz
In reply to this post by Stephen R. van den Berg
On Thu, Apr 1, 2021 at 9:18 AM Stephen R. van den Berg <[hidden email]> wrote:
>
> But in 8.1+ mode, I could imagine omitting the compatibility wrappers from
> the getgo.

What's the proposed benefit for not having wrappers? They cost
virtually nothing, we can easily carry them for ages to come... why
break existing code?
Reply | Threaded
Open this post in threaded view
|

Re: Compression.Lz4

Stephen R. van den Berg
Tobias S. Josefowitz wrote:
>> But in 8.1+ mode, I could imagine omitting the compatibility wrappers from
>> the getgo.

>What's the proposed benefit for not having wrappers? They cost
>virtually nothing, we can easily carry them for ages to come... why
>break existing code?

No hard argument there.  Cleanliness, mostly.
But it's fine.  I'll make stubs.
--
Stephen.