> It was not easy precisely because it had to strip out its own tools. If the > tools are remote then stripping is much easier. I'm not proposing stripping > as a standard step in deploying applications. I;m proposing stripping via > remote tools as a way to get down to a small kernel image. Part of the > difficulty in producing the small kernel image is needing to keep tools > around so that the development system keeps working. This is all much easier > if that development system is remote.
yes I imagine that well. > I think Craig has such a remote messaging scheme in Spoon. Yes he did. Now I tried it and try to ask some student to have a look but I failed. Long story.... > Was using distribution just one way to make sure that your two systems were > decoupled? > Because we could achieve the same using seaside? or > > Exactly. The TTIB serves as a specification and a filter. But it is > independent of the transport. Seaside is a valid transport. If things are > done right one can have many different kinds of UI. But one is making the > choice that the transport is Smalltalk messages over some non-Smalltalk > stream. No one is contemplating using SOAP or CORBA or... (I hope). we were thinking about checking rST > Yes, lots of things break potentally. Transcript, self confirm: etc. Part > of the challenge is in coming up with "pluggable" replacements. So that for > example Transcript in the target image is something that sends its output to > stdout until one attaches a tools UI, at which it becomes something that > sends its output to the Transcript in the UI image. This takes some thought > :) BTW this is exactly with this scenario in mind that we introduced TheUGLYANDBAD SmalltalkImage currrent "that we were so dumb to introduce" (guess who was bashing us instead of saying that we should finish..... Similarly this is not just for the sake of it that we replace most of the hardcoded Smalltalk by self class environment beause this way we could look in different images. Again this is not a lack of vision that slows us this was that we wanted to avoid to break and retrospectively we should have spend the 3 years doing 3.9 doing pharo. any way we had to try to do it with the community at that time. Stef _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
