For UI portability the only way to go is to have a clean separation between model and view. OmniBrowser, Glamour, ToolBuilder, Magritte, Pier, ... are examples of models that are independent of their view. Sport provides platform independence for files, sockets and exceptions. When we evaluated Sport for Seaside it only worked on VW and sockets were at the wrong abstraction level. Also to consider is that exceptions are pretty portable today. Grease is merely a collection of utilities to deal with strings, collections, encoding, message sends, versions and packages. It also includes a large collection of ANSI tests documenting what Seaside expects from the platform. For networking it depends on what you want to do. If you want sockets, then Sport is probably the way to go. If you want to serve HTTP then Seaside-Core is what I would pick: This does not include WAComponent and WASession, it provides platform independent request/response objects. Through adaptors it runs identically on all platforms that support Seaside and with many different web servers (for Pharo this is Zinc, Kom, KomLight, Swazoo, FastCGI, and probably others). As you see, all these examples work because they separate code that works on one platform and with one output format from the rest of the code. You can do this in any domain, but it is the easiest if you build on something that already works. An exception is PetitParser: It works on many platform without changes because it expects only a tiny subset of ANSI, the rests it simply implements itself or packages separately. Lukas -- Lukas Renggli www.lukas-renggli.ch