Squeak-dev July 1999

squeak-dev@lists.squeakfoundation.org

139 participants
367 discussions

Re: [ALL] Lobbying - Smalltalk KILLER APP!
by JArchibald＠aol.com 01 Jul '99

01 Jul '99

On 7/1/99 12:04:47 AM EDT, dway(a)mat.net writes: << Re: >> ... a "Smalltalk Web Server" to come on the scene. ..>> << Actually, the important thing is that it must be cross-platform in the sense of running on different OS platforms. I don't think it's necessary for it to work across multiple Smalltalk implementations (VW, VA, Dolphin, Squeak, etc.). >> Actually, wouldn't that fact that it ran on Unix (Linux) and NT be adequate. Almost all service providers today provide services in this form. Except for local networks, the other platforms don't currently provide many additional commercial realizations. The real problem, faced by some of recent mail in this distribution, is how to get commercial service providers (either Unix or NT) to host Swiki (Squeaky Wikis) web servers. Ward Cunningham showed us how to do this with CGI scripts (at least I think that's how the c2.com stuff works), and service providers do support private CGI hosting. I have several ideas that I would have started (as Squeak PWSs) if I had a commercial internet service provider that would allow me to run a Squeak program on their machines. I would like to be able to experiment with new PWS ideas, but even a 'fixed' Swiki implementation would be better than nothing. This is one case where we outside of academia may envy their more flexible resources. As an added footnote, solving this problem could be critical to the Squeakiness of the KILLER APP. This killer app (assuming that it's desirability is increasing) is also available in the original CGI form. Rapid success of PWSs without availability of commercial internet provider support for Squeak based PWSs would give the nod to CGI-based implementations (I see a number sprouting out there which are of this form). We've got to be able to see the same kind of availability for Squeak based ones. Jerry Archibald System Objectives

1 0

Re: [ENH] OS-level events
by Peter Smet 01 Jul '99

01 Jul '99

My understanding of events is much more basic than the others discussing this issue, but I have a naive question. Why are low level OS events like mouse clicks and keyboard strokes treated differently from a general events mechanism? By this I mean a mechanism for passing messages to 'subscribers' whenever an object emits an event (publish-subscribe)? It seems to me that any event still has an Object from which it originates, and one or more objects that will be told the event has occurred. Why can't low and high level events share the same abstractions, and even be placed on the same event queue? I also think exception-handling has much in common with event handling (on: exception do: aBlock). The exception looks to me very much like an 'event' that the block is told about. Is it possible to fuse these three mechanisms into a common abstraction and reuse a lot of the code, or is this just wishful thinking on my part? Peter From: Reinier van Loon <R.L.J.M.W.van.Loon(a)inter.nl.net> To: squeak(a)cs.uiuc.edu <squeak(a)cs.uiuc.edu> Date: Thursday, July 01, 1999 6:06 AM Subject: Re: [ENH] OS-level events >I keep getting the impression that the event systems designed so far are >only concerned with keyboard or mouse events. These events are then put in >an event queue with some information regarding the event. > >Why not define an event as <time, object> and event queue as a collection >sorted by time? >The global event (interrupt) handler detects an event on the queue (tim's >work) and gets the rest of the event of the object mentioned in the event. > >In this way, each object (keyboard, mouse, network, etc.) can have it's own >buffer. >And composite events are detected easily by comparing the time stamps. > >You could even start new processes to deal with events or have different >event handlers wait on the queues of the objects. No 'centralized' event >queue anymore. > >Just an idea. > >Reinier. > >

3 2

Re: [ALL] Lobbying - Smalltalk KILLER APP!
by Peter Smet 01 Jul '99

01 Jul '99

Yes! Yes! Yes! I think this is an excellent idea. As mentioned, the pluggable web server in Squeak is a great starting point. Mark Guzdial and others are modifying the Swiki servers to handle uploads, and the whole site is becoming very interactive. The next generation of pluggable web server is called commanche - I have noticed non-smalltalkers enquiring about the security and load aspects of the servers, so I suspect there is a big demand for a robust Smalltalk server. To find out more, do a search on PWS, pluggable web server, swiki etc, on the following home page: http://minnow.cc.gatech.edu/squeak.1 L. M. Rappaport wrote in message <377385ac.4116159(a)beavis.kronos.com>... >Another good starting place might be the PWS (programmable web server) >classes in Squeak. There is already an existing set of classes for >doing just that. Many SWIKI's are already running using this code. > >Larry >-- >rapp(a)lmr.com > > >Smalltalk4ever! <smalltalk4ever(a)my-deja.com> wrote (with possible >editing): > >>In article <7j74sq$ldq6(a)deagol.cc.flinders.edu.au>, >> "Peter Smet" <peter_smet(a)hotmail.com> wrote: >>> Stephan, >>> [stuff about increasing Smalltalk's public profile snipped] >>> These are all excellent points. >>> I would like to add one more. >>> >>> The visibility of Smalltalk would be hugely increased by an >>> 'open source killer app' >> >>OK - HERE'S THE KILLER SMALLTALK APP! [read on!] >> >>Sun and Netscape just "opened the door" for us... There's a TREMENDOUS >>opportunity for Smalltalk to have a killer app, right in front of us. >> >>Sun's JWS - Java Web Server - has been getting serious kudos from the >>web serving community for its performance over CGI - Since JWS serves >>pages with "lightweight threads" it's a LOT faster than CGI's running as >>UNIX processes. Smalltalk processes would be just as lightweight! >> >>The "Sun/Netscape Alliance" process identified a few Sun products that >>were in direct competition with Netscape products. In their infinite >>wisdom, the "Alliance" decided to "End-Of-Life" the Java Web Server >>product. The upcoming 2.0 release will be the LAST release of JWS. >> >>WAHOO! This is the perfect time for a "Smalltalk Web Server" to come on >>the scene. I know some work has already been done along these lines, >>but I don't remember it being free, nor do I see it (currently) being >>packaged in a way that a non-smalltalker "web administrator" could >>simply install and use. Most importantly, it should be cross-platform, >>i.e. it should work on VW and VA and Dolphin and whatever else people >>are hacking on nowadays... >> >>The JWS product is a good reference implementation; it already shows how >>a web server can integrate with existing CGI scripts, standard http and >>ftp and file services, and, most importantly, it lets developers bounce >>"servlets" up and down without bouncing the whole server up and down. >>While it's admin interface leaves a lot to be desired, any Web Server's >>admin interface needs to be at least as good as JWS's is. >> >>Man, this is exciting to me. It's not often I see a "killer app" >>opportunity as clearly as I see this one. >> >>Let's run with this, and kick some serious java-butt while we're at it. >> >>Eliot, James, Ralph, Eric, and Peter - - aw, heck, and anyone else who's >>interested - - Come On, Let's Make This HAPPEN! >> >>NOW is the time to "play the right cards" in the Web Server market. >> >>-Paul Reiber >>Smalltalk4ever! >>http://members.excite.com/directory/Smalltalk4ever >> >> >>Sent via Deja.com http://www.deja.com/ >>Share what you know. Learn what you don't. >

3 2

Re: [ENH] OS-level events
by Peter William Lount 01 Jul '99

01 Jul '99

Hi Peter, One difference with keyboard and mouse events it is that in the general case the "ACTIVE" window consumes them while the other windows ignore them unless the event is a one (like a button down event in an inactive window) that causes the window to become active. Drag and drop is an exception to this general rule where as you drag (with the mouse pressed down) over windows and their views "event" messages are generated for whatever window (active or inactive) is below the mouse. Also, the "active" window gets to "remove" events from the keyboard and mouse queue as it needs to. Another class of events that is useful to an application is the "Timer" event. Remote events from other system may not be relevant to a particular window unless they are "remote mouse and keyboard events". So we have events that appear on the event queue in different ways and we have events that need to be removed from the queue in different ways. Do we have different queues? Do we have one queue with different ways of distributing and consuming events? It's a design issue and each design choice will open up it's own issues. In NeXTStep/OpenStep/MacOSX there is an NSApplication object that is the "main" loop of an application program. This NSApplication instance reads the events, distributes the events to the current "event responder" in the current active window, and if no one consumes the event it it is then processed by the NSApplication instance itself to see if its a menu keyboard shortcut. This allows the NSApplication instance to have one steady stream of events, including remote events from the Portable Distributed Objects link an application can have, and respond to them apporpiately. First by asking if any other objects "respond" to the event, given the current context the application is in and then by handeling the event itself. So the design of a single event queue has been successful in at least one production system (that I know of). One of my questions is "what will happen to the Controller loop" with an event based Smalltalk"? I guess that it goes away and gets replaced by something like the NSApplication loop. I'll have to explore some event based Smalltalks to find out... What are you guys planning to do with the controller loops? All the best, Peter William Lount peter(a)smalltalk.org http://www.smalltalk.org ---------- From: Peter Smet <peter.smet(a)flinders.edu.au> To: squeak(a)cs.uiuc.edu Subject: Re: [ENH] OS-level events Date: June 30, 1999 4:02 PM My understanding of events is much more basic than the others discussing this issue, but I have a naive question. Why are low level OS events like mouse clicks and keyboard strokes treated differently from a general events mechanism? By this I mean a mechanism for passing messages to 'subscribers' whenever an object emits an event (publish-subscribe)? It seems to me that any event still has an Object from which it originates, and one or more objects that will be told the event has occurred. Why can't low and high level events share the same abstractions, and even be placed on the same event queue? I also think exception-handling has much in common with event handling (on: exception do: aBlock). The exception looks to me very much like an 'event' that the block is told about. Is it possible to fuse these three mechanisms into a common abstraction and reuse a lot of the code, or is this just wishful thinking on my part? Peter From: Reinier van Loon <R.L.J.M.W.van.Loon(a)inter.nl.net> To: squeak(a)cs.uiuc.edu <squeak(a)cs.uiuc.edu> Date: Thursday, July 01, 1999 6:06 AM Subject: Re: [ENH] OS-level events >I keep getting the impression that the event systems designed so far are >only concerned with keyboard or mouse events. These events are then put in >an event queue with some information regarding the event. > >Why not define an event as <time, object> and event queue as a collection >sorted by time? >The global event (interrupt) handler detects an event on the queue (tim's >work) and gets the rest of the event of the object mentioned in the event. > >In this way, each object (keyboard, mouse, network, etc.) can have it's own >buffer. >And composite events are detected easily by comparing the time stamps. > >You could even start new processes to deal with events or have different >event handlers wait on the queues of the objects. No 'centralized' event >queue anymore. > >Just an idea. > >Reinier. > >

1 0

Re: On Reuse
by John E Tobler 01 Jul '99

01 Jul '99

>From what I've seen, lately, some of the best reuse strategies involve components, whether CORBA, ActiveX, Enterprise Java Beans (EJB), or other architectures. You have to work with these on a somewhat "black box" level but they offer a powerful alternative to "cut and paste" reuse. I'm a Squeak newbie and I'm hopeful that I will see more Squeak/component interfacing as I get familiar with what's going on. Components have been immensely useful to me in my work in other languages and these days much of my time is spent creating them for others to use. When I get stronger in Squeak, I'd like to participate in component-oriented Squeak projects. BTW, I wouldn't at all mind some kindly references to any Squeak/component work being done! John Tobler cyberjet(a)cheerful.com

1 0

Re: On Reuse
by Terry Raymond 01 Jul '99

01 Jul '99

On Wed, 30 Jun 1999 22:39:18, Lex Spoon wrote: >Just because I needed a "POP component", and someone had written a "POP component", >didn't at all mean I could just pick theirs up and use it. (And likewise, just >because I write "a linux sound module" and someone else writes "a linux sound module", >they aren't necessarily duplicates! There've been at least four such modules to go >across this list, all with important differences). Components can be reused effectively only after they have been reused a few times. Very few people get it right the first time. So think of it this way, if you pick up someone else's code and modify it for your purposes and attempt to keep the changes general, then most likely it will be easier for someone else to reuse. Contributing to code development is not just writing new code, it is also refining and improving existing code. Terry Raymond Crafted Smalltalk (401) 846-6573 http://www.craftedsmalltalk.com

1 0

Re: On Reuse
by Geoff Canyon 01 Jul '99

01 Jul '99

One really good (although a little strange by most standards) example of reuse is XCMDs and XFCNs in HyperCard on the Mac. Because the code that is reused exists on an entirely different level from the code that does the "reusing," a well-defined interface between the two is unavoidable. For example, an XFCN might take a list of values and return it sorted according to specified criteria. There is no ambibuity--either the XFCN does what you want, or it doesn't. AppleScript OSAXen are another example. Plugins are another. Code reuse at a low level is hard; code reuse at a high level is much easier. Having a way of packaging up code for reuse, to enforce a clean and simple interface, might spur reuse in Squeak. just my two cents gc Geoff Canyon gcanyon(a)inspiredlogic.com Your child can learn to read using the classics of children's literature. Check out C.D. Caterpillar: <http://www.inspiredlogic.com/cd/>

1 0

Jump to page: