Re: [KinoSearch] Stable releases under new namespaces

[we...@ctosonline.org]

On Mar 14, 2010, at 5:21 PM, Marvin Humphrey wrote:

> On Sun, Mar 14, 2010 at 02:30:48PM -0500, Peter Karman wrote:
>> I like this approach. It's more work for KS developers, in terms of  
>> managing
>> api versions, but that's good work to do, since it requires making  
>> the api
>> changes very explicit.
>
> I understand that this sounds attractive in theory, but it's not  
> practical.
> Certainly having two versions run side by side won't ever work.  We  
> can't
> search-and-replace within compiled XS objects to substitute  
> "KinoSearch" for
> "KinoSearch3".  Does Query_Is_A(query, ORQUERY) pass, fail, or  
> segfault
> when "query" was created under KinoSearch3, but ORQUERY is a VTable  
> owned by
> KinoSearch4, aliased to KinoSearch?  What should factory methods  
> spit out, and
> how will they know?  How will type checking across the Perl/C border  
> work?

I don’t understand all of what you are saying, but I had in mind  
making KinoSearch an alias for KinoSearch4, and not vice versa.  
Running multiple versions in the same process I don’t consider a  
necessity. Does that change anything?

>
> Changing up behaviors using an api_version key can work within a  
> single
> object, using one of the following strategies:
>
>  * Store api_version as a member variable and switch up behavior  
> based on
>    its value.  That's what HTML::Parser does, I believe.
>  * Have the constructor dispatch based on api_version and return  
> objects
>    blessed into different classes.
>  * Store an API-specific object within the main object and dispatch  
> to that.
>
> However, KinoSearch is a highly performance-sensitive library with  
> hundreds of
> classes and lots of interaction between all the various parts.   
> Furthermore,
> it doesn't use hash-based method dispatch, but compile time binding  
> -- which
> is much faster, but also means that invoking an invalid method on an  
> object
> results in a memory error rather than a catchable exception.  At  
> best that's a
> segfault, at worst it's a security hole.
>
> Marvin Humphrey
>
>
> _______________________________________________
> kinosearch mailing list
> kinosearch@rectangular.com
> http://rectangular.com/cgi-bin/mailman/listinfo/kinosearch

Re: [KinoSearch] Stable releases under new namespaces

[Marvin Humphrey <ma...@rectangular.com>]

On Sun, Mar 14, 2010 at 06:16:25PM -0700, webmasters@ctosonline.org wrote:
> I don’t understand all of what you are saying, but I had in mind  
> making KinoSearch an alias for KinoSearch4, and not vice versa.  
> Running multiple versions in the same process I don’t consider a  
> necessity. Does that change anything?

Theoretically less impossible, but still impossible. :(  And I do think that
the inability to use the modules side by side while aliased is a major fault.
With the separate namespaces, it's actually possible for libraries with
dependencies on different stable forks of KS to co-exist happily.  That's not
true if everybody's fighting over who gets to own "KinoSearch".

What you describe would be hard to pull off for a pure Perl distribution of
substantial size.  (Race conditions as to which module gets loaded first
determines what version of KS gets aliased, oi...)  Once you add in the
compiled C code, the consequences of failure, and the fact that the Clownfish
object model is already ambitious and totally unprepared for being abused in
such a way, it's just not practical.

Marvin Humphrey