[openbeos] Re: general update tool idea

Kobi Lurie wrote: 
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

There are also many other messages, these were those I wrote (it's easier to look for your own name, heh). If you follow the threads, you'll see what others have proposed and discussed.

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.

But there's no *need* to make them "shared" per se, it's only a way to effectively organize your app into more manageable objects, and not stuff everything into a single executable image.

Sun did that with Java, but I don't think every class should live in its own object (.class); this sometimes doesn't make sense.

Of course that if you're going to design your app as a toolchain, its .so's could be shared by other applications.

as i understood it, components/plugins that share the same api across all programs is an amazing feat.
(next generation replicants)

It's more like the other way around... This *could* happen in the tools paradigm, but splitting a bigger .o into smaller .so's don't require this. But IMHO the tools paradigm would benefit a *lot* from it.

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.

Exactly.

u can probably break down existing programs in your mind, and see what the most common components are.

Uh-huh.

the compiled components themselves would get alot of work to be fast,
which is the gain of everybody else.

One of the nicest side-effects ^_^

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.

I did include this idea in the shape of what I called the "ToolWeb framework", which would describe a standard protocol for inter-tool communication... Kinda. Like I said, this needs some more polishing.

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?

Check the first link ^_^

anyway, let's keep this to ge. it needs alot of thought to make it succeed and simplify our life :))

That's our goal ^_^




--
"No hay banda! Todo esta' grabado!"


Other related posts: