Hi list,
we want to run a set of seaside sites in a server, where VW runs like a service (in a windows machine). Our idea of developing cycle is: 1. VW runs as a service in the server, preconfigured with a "deployment" Store account. 2. We develop and test locally in our "beta" store. 3. We publish tested versions in the "deployment" repository. 4. We ask the VW image acting as a service to reload the packages or add new ones. However, AFAIK applications running as services in windows are not allowed to have GUIs, thus we need an alternate way to manage the uploading of new packages to that image. So, I was wondering if anybody has already bumped in this situation and has a nice solution (or maybe I'm missing something). Any advice is most welcome. Thanks in advance, Andrés _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Generally I always made parcels, dropped them on the server in a
directory and bump the service which would autoload the parcels from that special directory. You could add an admin page on your seaside app to tell it to reload the parcels - James Robertson has code to do that too. Michael Andres Fortier wrote: > Hi list, > we want to run a set of seaside sites in a > server, where VW runs like a service (in a windows > machine). Our idea of developing cycle is: > > 1. VW runs as a service in the server, preconfigured > with a "deployment" Store account. > 2. We develop and test locally in our "beta" store. > 3. We publish tested versions in the "deployment" > repository. > 4. We ask the VW image acting as a service to reload > the packages or add new ones. > > However, AFAIK applications running as services in > windows are not allowed to have GUIs, thus we need an > alternate way to manage the uploading of new packages > to that image. So, I was wondering if anybody has > already bumped in this situation and has a nice > solution (or maybe I'm missing something). Any advice > is most welcome. > > Thanks in advance, > Andrés > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
You can programmatically connect/disconnet/load from Store - the
difficulty comes from things like the progress dialog and pre-reqs that require responses. 1) Load LessProgress, as it will eliminate the progress dialogs 2) It's less than optimal, but design your load script such that you load things in order, avoiding prompts that way James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On May 27, 2008, at 9:42 AM, Andres Fortier wrote: > Hi list, > we want to run a set of seaside sites in a > server, where VW runs like a service (in a windows > machine). Our idea of developing cycle is: > > 1. VW runs as a service in the server, preconfigured > with a "deployment" Store account. > 2. We develop and test locally in our "beta" store. > 3. We publish tested versions in the "deployment" > repository. > 4. We ask the VW image acting as a service to reload > the packages or add new ones. > > However, AFAIK applications running as services in > windows are not allowed to have GUIs, thus we need an > alternate way to manage the uploading of new packages > to that image. So, I was wondering if anybody has > already bumped in this situation and has a nice > solution (or maybe I'm missing something). Any advice > is most welcome. > > Thanks in advance, > Andrés > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
On Tue, 27 May 2008 10:42:13 -0300
Andres Fortier <[hidden email]> wrote: > 1. VW runs as a service in the server, preconfigured > with a "deployment" Store account. > 2. We develop and test locally in our "beta" store. > 3. We publish tested versions in the "deployment" > repository. > 4. We ask the VW image acting as a service to reload > the packages or add new ones. You could also fork a thread for periodically querying your store and loading the most recent code. > However, AFAIK applications running as services in > windows are not allowed to have GUIs, thus we need an > alternate way to manage the uploading of new packages > to that image. So, I was wondering if anybody has > already bumped in this situation and has a nice > solution (or maybe I'm missing something). Any advice > is most welcome. What I'm doing on a linux machine (headless VW) is similar to what I described above. A thread periodically looks for a file called patch.st, which is then loaded. This file could contain a load script or even just diff-fileouts of modified packages. HTH, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
What happens to your in-flight transactions as application shape
changes? You'd need some kind of atomic loading for this to work, no? -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf > Of Stefan Schmiedl > Sent: Tuesday, May 27, 2008 7:52 AM > To: [hidden email] > Subject: Re: [vwnc] VW + Seaside question > > On Tue, 27 May 2008 10:42:13 -0300 > Andres Fortier <[hidden email]> wrote: > > > 1. VW runs as a service in the server, preconfigured > > with a "deployment" Store account. > > 2. We develop and test locally in our "beta" store. > > 3. We publish tested versions in the "deployment" > > repository. > > 4. We ask the VW image acting as a service to reload > > the packages or add new ones. > > You could also fork a thread for periodically > querying your store and loading the most recent code. > > > However, AFAIK applications running as services in > > windows are not allowed to have GUIs, thus we need an > > alternate way to manage the uploading of new packages > > to that image. So, I was wondering if anybody has > > already bumped in this situation and has a nice > > solution (or maybe I'm missing something). Any advice > > is most welcome. > > What I'm doing on a linux machine (headless VW) is similar to what I > described above. A thread periodically looks for a file called > which is then loaded. This file could contain a load script or even > just diff-fileouts of modified packages. > > HTH, > s. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by James Robertson-7
On May 27, 2008, at 6:57 AM, James Robertson wrote: > You can programmatically connect/disconnet/load from Store - the > difficulty comes from things like the progress dialog and pre-reqs > that require responses. > > 1) Load LessProgress, as it will eliminate the progress dialogs > > 2) It's less than optimal, but design your load script such that you > load things in order, avoiding prompts that way You can even go a step further and automate this. Two packages come in handy for it. 1) UpdateFromStore. UpdateFromStore is kind of a grab bag, but amongst it's tools, it has the ability to discover from one package, all the other packages it will need and generate a load list for them. It does this by looking at the database directly, so you don't have to load the stuff into your own image. This has the nice effect that if you're using a Charting package, and someone decides that the latest version of that package will now use NumericCollections, it just works. You don't have to update your load scripts, since they're computed. Since it traces the prereq info, you don't have to repeat the same work to get the packages listed in the right order. 2) ParcelBuilder. Given a load list from the previous package, you can build a basic image with this tool, which will read those load lists and create parcels from them for you from your database. This code has examples of how to programatically connect/disconnect from Store. -- Travis Griggs Objologist "There are a thousand hacking at the branches of evil to one who is striking at the root" - Henry David Thoreau _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Boris Popov, DeepCove Labs (SNN)
On Tue, 27 May 2008 08:01:02 -0700
"Boris Popov" <[hidden email]> wrote: > What happens to your in-flight transactions as application shape > changes? You'd need some kind of atomic loading for this to work, no? There are no in-flight transactions with a current user base of 1 or 2 keeping office hours different from my dev hours :-) My patch approach (if I keep it for deployed apps with ~50 users at all) will then only be used to fix gui glitches or to initiate a "clean shutdown" for larger offline maintenance. Luckily my stuff is not required to run 24x7, so the next maintenance window is always right around the corner. s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Travis Griggs-3
First of all thank you very much for all your (really
quick) answers. I'll have a lot to look into :). Now, there is one thing I'm still wondering: isn't there a way to have an image act like a "remote view" of other? I mean, having a remote launcher/workspace/browser? Ideally I would like having a remote desktop, but that doesn't seem possible for the way windows handle services. So, I know that VNC-like clients can be implemented to act like a "duplicate" GUI, what would be really cool is to use local GUI to remote headless images. Has anybody tried something like this with Opentalk? Specially opening a browser to remotely edit a class that lives in another image? Thanks again, Andrés Travis Griggs escribió: > On May 27, 2008, at 6:57 AM, James Robertson wrote: > >> You can programmatically connect/disconnet/load from Store - the >> difficulty comes from things like the progress dialog and pre-reqs >> that require responses. >> >> 1) Load LessProgress, as it will eliminate the progress dialogs >> >> 2) It's less than optimal, but design your load script such that you >> load things in order, avoiding prompts that way > > You can even go a step further and automate this. Two packages come in > handy for it. > > 1) UpdateFromStore. UpdateFromStore is kind of a grab bag, but amongst > it's tools, it has the ability to discover from one package, all the > other packages it will need and generate a load list for them. It does > this by looking at the database directly, so you don't have to load > the stuff into your own image. This has the nice effect that if you're > using a Charting package, and someone decides that the latest version > of that package will now use NumericCollections, it just works. You > don't have to update your load scripts, since they're computed. Since > it traces the prereq info, you don't have to repeat the same work to > get the packages listed in the right order. > > 2) ParcelBuilder. Given a load list from the previous package, you can > build a basic image with this tool, which will read those load lists > and create parcels from them for you from your database. This code has > examples of how to programatically connect/disconnect from Store. > > -- > Travis Griggs > Objologist > "There are a thousand hacking at the branches of evil to one who is > striking at the root" - Henry David Thoreau > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
actually that has been one of the initial ideas behind Opentalk when it was invented. In the preview directory you'll find at least some first cuts at remote tools, namely a debugger and a profiler. They should give some hints how to possibly procede.
-----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Andres Fortier Gesendet: Dienstag, 27. Mai 2008 19:30 An: VWNC List Betreff: Re: [vwnc] VW + Seaside question First of all thank you very much for all your (really quick) answers. I'll have a lot to look into :). Now, there is one thing I'm still wondering: isn't there a way to have an image act like a "remote view" of other? I mean, having a remote launcher/workspace/browser? Ideally I would like having a remote desktop, but that doesn't seem possible for the way windows handle services. So, I know that VNC-like clients can be implemented to act like a "duplicate" GUI, what would be really cool is to use local GUI to remote headless images. Has anybody tried something like this with Opentalk? Specially opening a browser to remotely edit a class that lives in another image? Thanks again, Andrés Travis Griggs escribió: > On May 27, 2008, at 6:57 AM, James Robertson wrote: > >> You can programmatically connect/disconnet/load from Store - the >> difficulty comes from things like the progress dialog and pre-reqs >> that require responses. >> >> 1) Load LessProgress, as it will eliminate the progress dialogs >> >> 2) It's less than optimal, but design your load script such that you >> load things in order, avoiding prompts that way > > You can even go a step further and automate this. Two packages come in > handy for it. > > 1) UpdateFromStore. UpdateFromStore is kind of a grab bag, but amongst > it's tools, it has the ability to discover from one package, all the > other packages it will need and generate a load list for them. It does > this by looking at the database directly, so you don't have to load > the stuff into your own image. This has the nice effect that if you're > using a Charting package, and someone decides that the latest version > of that package will now use NumericCollections, it just works. You > don't have to update your load scripts, since they're computed. Since > it traces the prereq info, you don't have to repeat the same work to > get the packages listed in the right order. > > 2) ParcelBuilder. Given a load list from the previous package, you can > build a basic image with this tool, which will read those load lists > and create parcels from them for you from your database. This code has > examples of how to programatically connect/disconnect from Store. > > -- > Travis Griggs > Objologist > "There are a thousand hacking at the branches of evil to one who is > striking at the root" - Henry David Thoreau > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
As Helge pointed out, there has been some work on Opentalk
Tools, but it's not complete, and I don't know about the status.
Also, although it's not yet available, the work that's been done on Web Velocity tools might be of use in this circumstance. It provides a UI for developing, but one which runs in the web browser, using Seaside. It's not intended for managing an installation, but might be of some use there. And even standard Seaside provides a certain amount of capability in terms of inspectors and such. At 01:29 PM 5/27/2008, Andres Fortier wrote: First of all thank you very much for all your (really --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
Thanks for the information Alan. I think that web
management is the way to go, so I guess I will start by adding a couple of management pages. Are there any dates established for making Web Velocity available? thanks again, Andrés Alan Knight escribió: > As Helge pointed out, there has been some work on Opentalk Tools, but it's not complete, and I don't know about the status. > > Also, although it's not yet available, the work that's been done on Web Velocity tools might be of use in this circumstance. It provides a UI for developing, but one which runs in the web browser, using Seaside. It's not intended for managing an installation, but might be of some use there. And even standard Seaside provides a certain amount of capability in terms of inspectors and such. > > At 01:29 PM 5/27/2008, Andres Fortier wrote: >> First of all thank you very much for all your (really >> quick) answers. I'll have a lot to look into :). >> Now, there is one thing I'm still wondering: isn't >> there a way to have an image act like a "remote view" >> of other? I mean, having a remote >> launcher/workspace/browser? Ideally I would like having >> a remote desktop, but that doesn't seem possible for >> the way windows handle services. So, I know that >> VNC-like clients can be implemented to act like a >> "duplicate" GUI, what would be really cool is to use >> local GUI to remote headless images. Has anybody tried >> something like this with Opentalk? Specially opening a >> browser to remotely edit a class that lives in another >> image? >> >> Thanks again, >> Andrés >> >> Travis Griggs escribió: >>> On May 27, 2008, at 6:57 AM, James Robertson wrote: >>> >>>> You can programmatically connect/disconnet/load from Store - the >>>> difficulty comes from things like the progress dialog and pre-reqs >>>> that require responses. >>>> >>>> 1) Load LessProgress, as it will eliminate the progress dialogs >>>> >>>> 2) It's less than optimal, but design your load script such that you >>>> load things in order, avoiding prompts that way >>> You can even go a step further and automate this. Two packages come in >>> handy for it. >>> >>> 1) UpdateFromStore. UpdateFromStore is kind of a grab bag, but amongst >>> it's tools, it has the ability to discover from one package, all the >>> other packages it will need and generate a load list for them. It does >>> this by looking at the database directly, so you don't have to load >>> the stuff into your own image. This has the nice effect that if you're >>> using a Charting package, and someone decides that the latest version >>> of that package will now use NumericCollections, it just works. You >>> don't have to update your load scripts, since they're computed. Since >>> it traces the prereq info, you don't have to repeat the same work to >>> get the packages listed in the right order. >>> >>> 2) ParcelBuilder. Given a load list from the previous package, you can >>> build a basic image with this tool, which will read those load lists >>> and create parcels from them for you from your database. This code has >>> examples of how to programatically connect/disconnect from Store. >>> >>> -- >>> Travis Griggs >>> Objologist >>> "There are a thousand hacking at the branches of evil to one who is >>> striking at the root" - Henry David Thoreau >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
Hi Andres:
In my last VW web system (not Seaside) we decided that restarting the Windows service was fast enough that all we had to do was add the updated parcel to appropriate directory and bounce the service. Total turn-around was about 3 minutes. The start loaded the parcels to a base image and did the appropriate startup/initialization/DB login. It was "the simplest thing that could possibly work". YMMV On May 27, 2008, at 6:42 AM, Andres Fortier wrote: > Hi list, > we want to run a set of seaside sites in a > server, where VW runs like a service (in a windows > machine). Our idea of developing cycle is: > > 1. VW runs as a service in the server, preconfigured > with a "deployment" Store account. > 2. We develop and test locally in our "beta" store. > 3. We publish tested versions in the "deployment" > repository. > 4. We ask the VW image acting as a service to reload > the packages or add new ones. > > However, AFAIK applications running as services in > windows are not allowed to have GUIs, thus we need an > alternate way to manage the uploading of new packages > to that image. So, I was wondering if anybody has > already bumped in this situation and has a nice > solution (or maybe I'm missing something). Any advice > is most welcome. > > Thanks in advance, > Andrés > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc Thanks!! Joseph Bacanskas [|] --- I use Smalltalk. My amp goes to eleven. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
We do something similar but we deploy primed images that already have the code loaded, in which case service restart is literally within seconds if not subsecond. Of course you should only do that when no sessions are active in your image. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Joseph Bacanskas-4
Yes, this may be a possible solution. However, as Boris Said, yo have
to be sure no sessions are alive :). Thanks, Andrés Joseph Bacanskas escribió: > Hi Andres: > > In my last VW web system (not Seaside) we decided that restarting the > Windows service was fast enough that all we had to do was add the > updated parcel to appropriate directory and bounce the service. Total > turn-around was about 3 minutes. The start loaded the parcels to a base > image and did the appropriate startup/initialization/DB login. It was > "the simplest thing that could possibly work". > > YMMV > > On May 27, 2008, at 6:42 AM, Andres Fortier wrote: > >> Hi list, >> we want to run a set of seaside sites in a >> server, where VW runs like a service (in a windows >> machine). Our idea of developing cycle is: >> >> 1. VW runs as a service in the server, preconfigured >> with a "deployment" Store account. >> 2. We develop and test locally in our "beta" store. >> 3. We publish tested versions in the "deployment" >> repository. >> 4. We ask the VW image acting as a service to reload >> the packages or add new ones. >> >> However, AFAIK applications running as services in >> windows are not allowed to have GUIs, thus we need an >> alternate way to manage the uploading of new packages >> to that image. So, I was wondering if anybody has >> already bumped in this situation and has a nice >> solution (or maybe I'm missing something). Any advice >> is most welcome. >> >> Thanks in advance, >> Andrés >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > Thanks!! > Joseph Bacanskas [|] > --- I use Smalltalk. My amp goes to eleven. > > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
Which is how apache graceful works, once triggered it will let in flight requests finish on any given worker then recycle itself. I was planning on implementing something very similar here by suspending registration of new sessions and letting load balancer direct new requests to a different pool member and recycling the service when last session expires. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Alan Knight-2
Am 28.05.08 14:19 schrieb "Alan Knight" unter <[hidden email]>:
> As Helge pointed out, there has been some work on Opentalk Tools, but it's not > complete, and I don't know about the status. As an aside, with probably no practical relevance at all after all those years: Georg Heeg's company once had an awesome little product called RemoteObjects. It offered pure Smalltalk-to-Smalltalk remote communications, transparently sending Smalltalk messages over the network, just as in Opentalk or from VisualWorks to GemStone/S. What made it über-cool besides the fact that it was implemented about 15 years ago: It had complete and fully functional remote browsers, inspectors and debugging tools. You could debug a process and follow the messages across the network as if everything happened in your local image, regardless of the number of Smalltalk images talking to each other. Or just edit the code in a remote image. In the debugger, too. It's probably lost in software nirvana now. Too bad. Back in those days, customers thought it a good idea to base remote communication on CORBA instead of buying RemoteObjects, because CORBA was such a promising standard and would certainly outlive everything Smalltalk. Anybody having a déja-vu here, in the modern times of WS*? Joachim Geidel _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I have used the RemoteUI goodie in VisualAge to probe a packaged server
to good effect... As you say, über-cool! Stewart >-----Original Message----- >From: [hidden email] [mailto:[hidden email]] On Behalf >Of Joachim Geidel >Sent: 31 May 2008 6:23 a.m. >To: VWNC List >Subject: Re: [vwnc] VW + Seaside question > >Am 28.05.08 14:19 schrieb "Alan Knight" unter <[hidden email]>: >> As Helge pointed out, there has been some work on Opentalk Tools, but >it's not >> complete, and I don't know about the status. > >As an aside, with probably no practical relevance at all after all >years: > >Georg Heeg's company once had an awesome little product called >RemoteObjects. It offered pure Smalltalk-to-Smalltalk remote >communications, >transparently sending Smalltalk messages over the network, just as in >Opentalk or from VisualWorks to GemStone/S. What made it über-cool besides >the fact that it was implemented about 15 years ago: It had complete and >fully functional remote browsers, inspectors and debugging tools. You could >debug a process and follow the messages across the network as if everything >happened in your local image, regardless of the number of Smalltalk images >talking to each other. Or just edit the code in a remote image. In the >debugger, too. > >It's probably lost in software nirvana now. Too bad. Back in those days, >customers thought it a good idea to base remote communication on CORBA >instead of buying RemoteObjects, because CORBA was such a promising >standard >and would certainly outlive everything Smalltalk. Anybody having a déja-vu >here, in the modern times of WS*? > >Joachim Geidel > > > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Joachim Geidel
Am 30.05.2008 um 20:23 schrieb Joachim Geidel: > It's probably lost in software nirvana now. Too bad. Back in those > days, > customers thought it a good idea to base remote communication on CORBA > instead of buying RemoteObjects, because CORBA was such a promising > standard > and would certainly outlive everything Smalltalk. Anybody having a > déja-vu > here, in the modern times of WS*? Oh yes. This happens all the time. The path to success looks probably like this: Focus on a concept that is as generic and universal as possible. Pick a phonetically fluid acronym that doesn't explain anything. Treat it like a religious fetish, keep talking about it in mysteries and mantras and make everyone feel their souls get lost unless they jump on the bandwagon. This way you get a hype even before the first 10% of the crowd actually understood what it's all about ;-) I remember the days when I first heard about "Java" - ja wah ah ah ah. I knew nothing about it and had no time to look at it any closer, but I instinctively chimed in and spread the word about this cool thing that was supposed to change the world. Andre BTW: Why don't we just call it "Smaraboo" ? .. boo hoo. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |