Wow, thanks for thinking about my ideas. I expected that you call me a troll, but it seems that there are cool people here ;-)
O.K. lets simply call it class-library.
It doesn't seem to be the Perl way to limit yourself to one option
only ("There's more than one way to do it"). Of course we wouldn't
want five different implementations of Unicode, and it makes sense to
ship _one_. However, people might want to use different GUIs --
e.g. wxWindows, TK, native Windows GUI, Aqua, ...
In my opinion wxWindows would be fine with a nice api-binding.
The C++-Api is terrible, but the toolkit itself seems to offer quite cool features.
I would prefer wxWindows, because they did what Sun didnt continue.
One API many toolkits, small library-size.
Of course, many people have different tastes, but look at Java (thats the world where I come from).
swing is slow and ugly, but nearly 97% of all java programs use it because its shipped with java since 1.2...
Look at TCL, TK is used because it integrates well with TCL.
If one really doesnt like wxWindows, he can of course provide other libraries.
But the mainstream will use the libraries provided with the runtime.
Sound is a whole different beast -- implementations vary
wildly across systems, and I'm not sure whether it is possible to have
a high-performance cross-platform implementation that satisifes 90% of
users.
SDL shows that this is possible.
Of course, its often a problem of portability.
But developers also have to think about portability. If the class-libraries shipped with a runtime-enviroment are available across most ports, they dont have to use 3 different bindings to different native libs. They can simply use the api implemented in the class-library and work with it.
For the developers of the class library this is of course hard work and the runtime often gets big.
- Parrot bytecode executables might be packages that contain the necessary libraries in bytecode format (e.g. wxWindows). - Installers might include libraries (in bytecode) and install them if needed (install = simple copy)
Bytecode-packages are typically no problem. They are small and only depend on libraries provieded by the enviroment.
For binary (platform-dependant) packages:
Usually, people just ship these statically linked against those libs that can't be typically expected to be installed on the system. So I guess for Parrot apps distributed in binary, there's not much of a problem. For apps shipped as bytecode, it still needs to be discussed what is going to be provided:
- Preferably a small package (< 5 - 10 MB) that lets people use Parrot apps
quickly.
- A huge package complete with Perl/Python/PHP/Befunge/hq9+/... support so that everybody will have 95% of everything they are ever gonna need
- Or both?
Of course, both would be best ;-).
In my opinion it would be best, to provide a native basis. "Lightweight"-libraries could do the rest.
However the user has to install native libraries, he has the good old problems:
*ABI problems
*Dependencies
*............
Of course, in parts where high-performance is needed, this wont be a good solution.
Of course it would be fine to have a package that only weights 5Mb, but what if the user needs to install 3 different libraries so that the user can use its program.
Imagine how much fits in a 15Mb RPM.....
A very important thing is in my eyes, that bindings can be created without the need of native code. e.g. JNI-bindings need to be written using C, theres no way to do everything in Java.
Maybe I can help creating such a class-library?
How hard do you think will it be to create a library which works good for many languages. E.G. Java has interfaces, I dont know about perl or python. But I´m sure perl has language features that java doesnt have....
Mochts as guat, Clemens *real Austrian slang*
