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@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.