I'm sorry but i think u misunderstood my first post. i read about 15 days of mail on the ge list, and all the "tools" posts. you're talking about a whole different way of programming. something that takes some time to design so users can appreciate its power.
I actually didn't: http://beunited.org/pipermail/glasselevator_beunited.org/2002-May/000084.html Check the before-last paragraph, and then the 4th pagragraph I've written in http://beunited.org/pipermail/glasselevator_beunited.org/2002-May/000086.html and also check the bottom of http://beunited.org/pipermail/glasselevator_beunited.org/2002-May/000107.html and finally this: http://beunited.org/pipermail/glasselevator_beunited.org/2002-May/000214.html
a really great concept, but i was only talking about updating apps/libs.
updating one lib which alot of apps link against would also prove to take less bandwidth/space, but i would very much like to get away from library conflicts,
(old and therefore not compatible with my app/ new and therefore not yet compatible with my app)
stuff that is going on with red hat rpm hell, and let's not forget windows dll hell.
beos is small and i like it that way.
it's just that when talking about shared libraries there's the stable, and there's the latest and sometimes it's problematic.
Exactly what I http://beunited.org/pipermail/glasselevator_beunited.org/2002-May/000214.html and Helmar http://beunited.org/pipermail/glasselevator_beunited.org/2002-June/000219.html said, no?
in optimized i mean that since they're shared code it's more likely that programmers would work to make it fast.
as i understood it, components/plugins that share the same api across all programs is an amazing feat.
(next generation replicants)
basically u can use ruby or other scripting language, control the layout with app_kit api or some xml layout api,
then put the right component which is already a compiled piece into the right place.
u can probably break down existing programs in your mind, and see what the most common components are.
the compiled components themselves would get alot of work to be fast, which is the gain of everybody else.
the only thing is that u don't include them in, u don't compile them in your app, but use them "outside" of it which would mean creating an api for c++ or scripting languages so power users can take advantage of this system.
this is very ge and needs a good design and goals from the start.
also, this all works great in your head when u think about gui but when it comes to network protocols (as http/ftp/irc/etc..) how would u abstract that?
anyway, let's keep this to ge. it needs alot of thought to make it succeed and simplify our life :))
-- "No hay banda! Todo esta' grabado!"