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 :-))
Pd-externals are usually FLOSS. this gives us the technical permission to duplicate the code. it is not necessarily a social permission.
mfgad.sr IOhannes