[PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)

[Hans-Christoph Steiner]

On Sep 18, 2007, at 9:43 AM, IOhannes m zmoelnig wrote:

> Georg Holzmann wrote:
>> Hallo!
>>
>>> as far as i have understood it, the standard library wants to  
>>> duplicate
>>> externals: e.g. an object that allows interfacing with the serial  
>>> port
>>> would be a copy of iem/comport that is named hardware/comport (or  
>>> whatever).
>>> thus it would not rely on "3rd party" externals, but on stdlib
>>> "internal" libraries. (with duplicate code and everything that  
>>> follows
>>> from it)
>>
>> As far as I undestood it the code of e.g. comport would go in this
>> standard lib (e.g. to hardware/comport) but should not duplicate the
>> code - instead the iem/comport code should be obsolete and now
>> maintained in hardware/comport.
>
> that is obviously the idea of the stdlib maintainers.
>
> nevertheless, it assumes that the auther of a certain object would
> happily give up "their" object and either maintain a stdlibized  
> version
> or withdraw from maintaining the object alltogether (and someone else
> maintains the stdlibized version)
>
> i guess, the 1st option is the one we would want to see happen.
>
> nevertheless i have some doubts: often, objects can not simply be
> "moved" into the stdlib, but they should follow some "standard" (hence
> the name!) design principles (of the interface).
> but changing the interface of an object is a heavy modification, which
> needs a lot of social competence)
> (i am pretty sure that there are lots of ideas how to make objects in
> zexy more "consistent" with other objects, however i have spend a  
> lot of
> time in designing the API (at least for some of them :-))

They key difference would be that each stdlib would have a  
standardized interface, and each objectclass would conform to that  
interface.  For example, there could be an 'io' standard lib.   
Everything in that lib would respond to [open(, [close(, etc. in the  
same way, the first inlet would behave similarly, and the first  
outlet would be the data in the form of lists, and the second outlet  
would be status info in the form of lists.

So no, I don't think we should just copy over existing code without  
change.  Instead, we should use existing code when it's useful, but  
focus on having a clean and consistent interface for each library.

Then the old "author's name" libraries, like iem, zexy, ggee, etc.  
would remain in place for backwards compatibility.


> Pd-externals are usually FLOSS.
> this gives us the technical permission to duplicate the code. it is  
> not
> necessarily a social permission.

Why use a free license then?  That just needlessly complicates  
things.  If someone doesn't want people freely using their code, then  
they should say so overtly.  Not, "my license says you can use my  
code, but if you do, then I'll get mad and work against you".

.hc

>
> mfgad.sr
> IOhannes
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

If you are not part of the solution, you are part of the problem.