Taking Swazoo Forward [Long]

>
> Hi all,
>
> I've finally had a little bit of time to look at the 0.9.1 code.  First
> of all, I want to thank Janko for all of the work he's done on Swazoo
> recently.  In addition to the coding work he's done, his activity has
> given us all a little push to get back into the Swazoo groove.
>
> I also wanted to ask everyone how well SourceForge is working.  Are
> people able to use the parcels now?  If it's a paoin to use, it'll deter
> people from working collaboratively on Swazoo.  That's bad.
>
> Personally, I find use of SourceForge (and CVS) for Swazoo development
> under Linux to be so-so.  If Smalltalk mapped into flat files more
> easily, perhaps it'd be better.  If I'm the only one checking things in,
> then it's fine.. but it can become a pain when we have several people
> working on the project.  I'd like our team to take a good look at CVST,
> since it seems to be coming along quite nicely (they're calling it
> "beta" now, and they're using it for CVST development).  Does anybody
> else think this would be a good idea?
>
> One downside of CVST (at present) are that a Dolphin version isn't done
> yet (it's "in the works", according to the project page).  The VW3 and
> Squeak versions apparently work well.
>
> One of the main reasons that I'm bringing this up is that I've noticed
> us getting a little out of sync in our development.  Before Janko's
> changes, we had a set of chunk files that were up to date.  We also had
> some VisualWorks 3.x parcels that were up to date, along with some 5i
> parcels that were a little outdated IIRC -- and a Dolphin port based
> on our somewhat outdated camp0.9 parcels.  Janko's changes are based on
> the camp0.9 parcels, too, so now we have a real maintenance nightmare on
> our hands.  That's not Janko's fault; it'd be almost as bad even if he'd
> based his changes on the latest-and-greatest parcels from SourceForge.
>
> The real challenge comes in merging Janko's changes (where appropriate)
> into the current Swazoo base -- and it turns out that there are a number
> of changes.  During CampST, the integration team was able to, well...
> integrate... the changes made by all other teams very quickly.  The
> situation is a little different now, and everybody needs to take some
> _personal_ responsibility for keeping things well-integrated, as I'm
> sure everyone knows.  That means that, if at all possible, changes to
> the code should be made in cooperation with the rest of the Swazoo
> team.  It'll cause headaches if anybody goes off into a corner and codes
> for more than a couple of days.
>
> With that said, I'd like to propose a bit of a "Swazoo etiquette".
> Here's how it goes.  If you see something in Swazoo that you'd like to
> change, send an email to the list.  Tag its subject with [PROP] (for
> "proposal").  Proposals should be concrete, quantifiable, and testable
> -- much like an XP story card.  Perhaps a proposal could even show a
> SUnit code snippet -- if you want quick approval from the other team
> members, this would be smart.  :)
>
> Everyone who receives a proposal message and cares about what goes into
> Swazoo should read these messages as soon as they can.  Replies to
> proposals should be technical.  We can discuss proposals, propose
> alternatives (if they exist), and then somebody can take responsibility
> for the change.
>
> Obviously, we can't do this for everything (e.g., "can I please add a
> cascade to the messages in HTTPServer>>#getAndDispatchMessages?").
> We're all decent developers, and we can use our best judgement here.
> But, when we're talking about adding or removing capabilities, fixing
> bugs, etc., I think it's important that we find the best way of
> accomplishing the task.
>
> Once again, the tests are crucial to integration.  I don't mind the idea
> of having tests in a separate parcel / CVS module -- it might make
> deployment a little simpler.  I think this would be easy to manage using
> CVST.
>
> No matter what direction we go for future code control (or future
> etiquette), we still have a bit of a problem now.  We have Janko's
> changes, based on camp0.9, and we need to figure out (a) which ones we
> want to keep just as they are and (b) which ones we want to borrow ideas
> from while creating a system that everybody likes.  From that
> perspective, here's my take.  I'll go through on a class by class basis,
> trying to pick out what the intent behind the changes is:
>
> HTTPConnection
> -----
> *Behavior: Added capability to keep timestamps for creation of the class
> and the time at which the last request was processed.  Added capability
> to run the get/send message loop at different priorities.  The
> connection now hangs onto the peer address rather than setting it in the
> newly created HTTPMessage.  Various methods renamed.
> *State: added 3 inst vars (timestamps, peerAddress, priority), renamed
> one (loop -> serveLoop).
>
> Janko has mentioned that these are for a future priority-downgrading
> algorithm.  Janko, please correct me if I'm wrong.  There are no senders
> of #timestamps, #lastRequestTimestamp, or #createdTimestamp in the
> parcel, so I can't tell what they're used for (if anything yet).  The
> same goes for the priorities.  Have you implemented this algorithm, or
> is it simply being planned?
>
> If the algorithm hasn't been implemented yet, and you feel that it is
> necessary, then you should make your case in a [Prop]osal -- algorithms
> can be tested nicely with SUnit.  Until then, I'd say "you aren't gonna
> need it" (YAGNI, from XP).
>
> For some of the method renaming, can we discuss this on the list?
>
> HeaderField
> -----
> *Behavior: #trimBlanks moved out of String and into this class as
> #trimBlanks:.
>
> Some subclasses still send #trimBlanks to the string, and HTTPPost uses
> #trimBlanks when reading itself off of a stream.  Added #printString
> which returns the field's value.
>
> As far as #trimBlanks goes, I'm somewhat split on this one -- part of me
> thinks, "Do it in a more portable, less conflict-causing way".. that is,
> define it somewhere in one of our classes.  The other part of me says,
> "do it right.  Once and only once."  What do others think?
>
> For the printString, why is just the value printed?
>
> CompositeResource:
> -----
> *Behavior: added #includesResource: testing method.  This is used by the
> HTTPServer when adding a site to make sure it doesn't add the site
> twice.
>
> I'm not quite sure why we need to make sure of this... Janko, can you
> please elaborate?  Perhaps somebody has put the same site into the
> sites.cnf file twice?  Are there any other conditions where this causes
> a problem?
>
> SiteIdentifier:
> -----
> *State: renamed 2 inst vars (ip -> address, host -> hostname).  Creation
> method changed from #ip:port:host: to #hostname:address:port:.
>
> I like these two renames -- they're a little more clear than the
> previous names.  I also like having hostname be the first part of the
> hostname:address:port: creation method, because it seems more logical
> that way.  We should write this up as a proposal.
>
> HTTPServer:
> -----
> *Behavior: various method renames.  Added lock around #addSite:,
> #removeSite: #getResourceFor:using:, #addConnection:,
> #removeConnection.  Split up #isServing into two parts (serveLoop is
> active and socket is active).  Listening socket is closed on server
> stop.  Various socket options set (soReuseaddr).
> *State: added 2 inst vars (socket, lock).
>
> IMHO, method renames should be discussed on the list.  The things that
> make sense to one person can seem strange to another.
>
> I'm not sure I quite understand the motivation for locking around access
> to the connections, sites, and the finding of the appropriate resource.
> Can you explain?  You might be able to describe a case where two
> HTTPConnections try to remove themselves simultaneously (my hunch is
> that the ST process model handles this for us), but I can't think of any
> where they'd be added simultaneously.  The only sender of #addConnection
> is #interactWithNewConnectionOver:, and this is all done from the single
> loop inside of HTTPServer.  I see no race conditions there.  Sites are
> only added and removed by the site registry -- do you envision sites
> being added and removed from multiple threads?  Perhaps you have a
> system where two administrators will be working on a site hierarchy at
> the same time?  And why is it needed around the #getResourceFor... ?
>
> I like the fact that your code closes the listening socket when the
> server is stopped.  This makes good sense to me, and it will probably
> mean that you don't need to set the soReuseaddr option.  I think we
> should write this up in a proposal message, too.  Janko, I'll do the
> proposal to rename the SiteIdentifier messages/vars, and I'll let you do
> this one.  :)
>
> HTTPResponse:
> -----
> *Behavior: #printOn: added, which dumps the status of the response (e.g.
> "HTTP/1.1 200 OK").   Extracted server string into its own message
> #serverIntroduction) and changed to use a dynamic version (Swazoo
> version).
>
> I like your printOn: method -- it'd be handy for debugging.  I don't
> think you need a CR after it, though.  If another object needs CRs
> (because it's printing a bunch of these), it should add them itself.
>
> The method HTTPResponse class>>#new that you've added is redundant,
> since it inherits the exact same thing from HTTPMessage.
>
> I also like the idea of having a dynamic version number for Swazoo.  We
> also need to make sure that the format of our version number matches the
> HTTP RFCs.
>
> As a side note, the class comment in the 0.9.1 parcel says "Copyright
> (c) Kazuki Yasumatsu, 1995...".  This was a little surprising.  :)
> Perhaps he wrote a class by the same name for SmallWalker, but this
> class particular class was written for Swazoo.
>
> HTTPRequest:
> -----
> *State: renamed 2 inst vars (ip -> serverAddress, peer -> peerAddress)
>
> I want to rename these two variables, too.. but I'm not quite convinced
> that these are the best names.   What do others think?
>
> As a side note, the printString in this object is really ugly.  I think
> that #printOn: and friends should be used for debugging purposes.. what
> do you want to see when inspecting this object?  If you want to have a
> nice printer for a logging facility, that should go in a different
> method.
>
> SiteRegistry / Swazoo
> -----
> State: no more Singleton class var.  Instead, the singleton is stored in
> a global variable.  Sites are started and stopped at appropriate times
> during snapshot, image shutdown, and image startup.
>
> I have little to add to the discussions about class names, except that
> it's worth noting that the three most significant classes (as far as
> "learning the system" goes) are in a class category called
> "Swazoo": SiteRegistry, HTTPServer, and HTTPConnection.  That alone
> should give people a good hint about where to start.
>
> I'm not sure what to think about the starting/stopping servers during
> snapshot.  During development, this might be handy.  During deployment,
> is it needed?  For Signal Ground, I made a headless image whose
> hlstrc.st file contains one line: SiteRegistry
> configureFrom: 'sites.cnf'.  That starts it up when the image starts.  I
> have noticed that it doesn't seem to release the socket quite right when
> I kill the "visual" process, but I'm not sure if ObjectMemory sends out
> its updates when the VM is killed via kill -15.  :)  What do others
> think about this?
>
> For now, keeping the Singleton in a global variable seems like another
> YAGNI.  When we have a need for this kind of behavior, we'll add it.
>
> Site
> ----
> *Behavior: #start and #stop added.  Can tell you if it's started.
> Starts and stops itself by communicating with the registry.
>
> Janko, we have a mechanism that lets you "turn off" a site for a while
> -- its called isEnabled.  Can we use this instead of the site
> #start/stop?
>
> Character & CharacterArray
> -----
> *Behavior: changes to #decodedHTTP.
>
> I can see how the original version would break if the data was
> truncated.. but I'm not sure about the way you attempt to solve this.
> Perhaps you should write a test case or two -- so that I can see what
> you expect as results from some truncated input.  Write this up as a
> proposal, too, and send it to us.  :)
>
> ------------
>
> Whew!
>
> Janko, please let me know if I've missed something.  I apologize to
> everybody for this monstrosity of a post.. but I think it's important
> that we look at these things carefully.
>
> Ken
>
> ----
> Ken Treis
> [hidden email]
>
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> http://lists.sourceforge.net/mailman/listinfo/swazoo-devel

> Hi Ken and others,
>
> Sorry, that I still didn't reply to your mail, I'm in the
> middle of lecturing one course, expect me back in Thursday.
>
> In the meantime, please help me preparing for OOPSLA
> presentation about Swazoo-Aida. I had one presentation at
> ESUG conference already, which was more Aida centric. On
> OOPSLA I'd like to talk more about Swazoo and less about
> Aida. Therefore, I anyone has some ideas about what and how
> to present Swazoo, please put them forward.
>
> Regards
> Janko
>
> Ken Treis wrote:
> >
> > Hi all,
> >
> > I've finally had a little bit of time to look at the 0.9.1 code.  First
> > of all, I want to thank Janko for all of the work he's done on Swazoo
> > recently.  In addition to the coding work he's done, his activity has
> > given us all a little push to get back into the Swazoo groove.
> >
> > I also wanted to ask everyone how well SourceForge is working.  Are
> > people able to use the parcels now?  If it's a paoin to use, it'll deter
> > people from working collaboratively on Swazoo.  That's bad.
> >
> > Personally, I find use of SourceForge (and CVS) for Swazoo development
> > under Linux to be so-so.  If Smalltalk mapped into flat files more
> > easily, perhaps it'd be better.  If I'm the only one checking things in,
> > then it's fine.. but it can become a pain when we have several people
> > working on the project.  I'd like our team to take a good look at CVST,
> > since it seems to be coming along quite nicely (they're calling it
> > "beta" now, and they're using it for CVST development).  Does anybody
> > else think this would be a good idea?
> >
> > One downside of CVST (at present) are that a Dolphin version isn't done
> > yet (it's "in the works", according to the project page).  The VW3 and
> > Squeak versions apparently work well.
> >
> > One of the main reasons that I'm bringing this up is that I've noticed
> > us getting a little out of sync in our development.  Before Janko's
> > changes, we had a set of chunk files that were up to date.  We also had
> > some VisualWorks 3.x parcels that were up to date, along with some 5i
> > parcels that were a little outdated IIRC -- and a Dolphin port based
> > on our somewhat outdated camp0.9 parcels.  Janko's changes are based on
> > the camp0.9 parcels, too, so now we have a real maintenance nightmare on
> > our hands.  That's not Janko's fault; it'd be almost as bad even if he'd
> > based his changes on the latest-and-greatest parcels from SourceForge.
> >
> > The real challenge comes in merging Janko's changes (where appropriate)
> > into the current Swazoo base -- and it turns out that there are a number
> > of changes.  During CampST, the integration team was able to, well...
> > integrate... the changes made by all other teams very quickly.  The
> > situation is a little different now, and everybody needs to take some
> > _personal_ responsibility for keeping things well-integrated, as I'm
> > sure everyone knows.  That means that, if at all possible, changes to
> > the code should be made in cooperation with the rest of the Swazoo
> > team.  It'll cause headaches if anybody goes off into a corner and codes
> > for more than a couple of days.
> >
> > With that said, I'd like to propose a bit of a "Swazoo etiquette".
> > Here's how it goes.  If you see something in Swazoo that you'd like to
> > change, send an email to the list.  Tag its subject with [PROP] (for
> > "proposal").  Proposals should be concrete, quantifiable, and testable
> > -- much like an XP story card.  Perhaps a proposal could even show a
> > SUnit code snippet -- if you want quick approval from the other team
> > members, this would be smart.  :)
> >
> > Everyone who receives a proposal message and cares about what goes into
> > Swazoo should read these messages as soon as they can.  Replies to
> > proposals should be technical.  We can discuss proposals, propose
> > alternatives (if they exist), and then somebody can take responsibility
> > for the change.
> >
> > Obviously, we can't do this for everything (e.g., "can I please add a
> > cascade to the messages in HTTPServer>>#getAndDispatchMessages?").
> > We're all decent developers, and we can use our best judgement here.
> > But, when we're talking about adding or removing capabilities, fixing
> > bugs, etc., I think it's important that we find the best way of
> > accomplishing the task.
> >
> > Once again, the tests are crucial to integration.  I don't mind the idea
> > of having tests in a separate parcel / CVS module -- it might make
> > deployment a little simpler.  I think this would be easy to manage using
> > CVST.
> >
> > No matter what direction we go for future code control (or future
> > etiquette), we still have a bit of a problem now.  We have Janko's
> > changes, based on camp0.9, and we need to figure out (a) which ones we
> > want to keep just as they are and (b) which ones we want to borrow ideas
> > from while creating a system that everybody likes.  From that
> > perspective, here's my take.  I'll go through on a class by class basis,
> > trying to pick out what the intent behind the changes is:
> >
> > HTTPConnection
> > -----
> > *Behavior: Added capability to keep timestamps for creation of the class
> > and the time at which the last request was processed.  Added capability
> > to run the get/send message loop at different priorities.  The
> > connection now hangs onto the peer address rather than setting it in the
> > newly created HTTPMessage.  Various methods renamed.
> > *State: added 3 inst vars (timestamps, peerAddress, priority), renamed
> > one (loop -> serveLoop).
> >
> > Janko has mentioned that these are for a future priority-downgrading
> > algorithm.  Janko, please correct me if I'm wrong.  There are no senders
> > of #timestamps, #lastRequestTimestamp, or #createdTimestamp in the
> > parcel, so I can't tell what they're used for (if anything yet).  The
> > same goes for the priorities.  Have you implemented this algorithm, or
> > is it simply being planned?
> >
> > If the algorithm hasn't been implemented yet, and you feel that it is
> > necessary, then you should make your case in a [Prop]osal -- algorithms
> > can be tested nicely with SUnit.  Until then, I'd say "you aren't gonna
> > need it" (YAGNI, from XP).
> >
> > For some of the method renaming, can we discuss this on the list?
> >
> > HeaderField
> > -----
> > *Behavior: #trimBlanks moved out of String and into this class as
> > #trimBlanks:.
> >
> > Some subclasses still send #trimBlanks to the string, and HTTPPost uses
> > #trimBlanks when reading itself off of a stream.  Added #printString
> > which returns the field's value.
> >
> > As far as #trimBlanks goes, I'm somewhat split on this one -- part of me
> > thinks, "Do it in a more portable, less conflict-causing way".. that is,
> > define it somewhere in one of our classes.  The other part of me says,
> > "do it right.  Once and only once."  What do others think?
> >
> > For the printString, why is just the value printed?
> >
> > CompositeResource:
> > -----
> > *Behavior: added #includesResource: testing method.  This is used by the
> > HTTPServer when adding a site to make sure it doesn't add the site
> > twice.
> >
> > I'm not quite sure why we need to make sure of this... Janko, can you
> > please elaborate?  Perhaps somebody has put the same site into the
> > sites.cnf file twice?  Are there any other conditions where this causes
> > a problem?
> >
> > SiteIdentifier:
> > -----
> > *State: renamed 2 inst vars (ip -> address, host -> hostname).  Creation
> > method changed from #ip:port:host: to #hostname:address:port:.
> >
> > I like these two renames -- they're a little more clear than the
> > previous names.  I also like having hostname be the first part of the
> > hostname:address:port: creation method, because it seems more logical
> > that way.  We should write this up as a proposal.
> >
> > HTTPServer:
> > -----
> > *Behavior: various method renames.  Added lock around #addSite:,
> > #removeSite: #getResourceFor:using:, #addConnection:,
> > #removeConnection.  Split up #isServing into two parts (serveLoop is
> > active and socket is active).  Listening socket is closed on server
> > stop.  Various socket options set (soReuseaddr).
> > *State: added 2 inst vars (socket, lock).
> >
> > IMHO, method renames should be discussed on the list.  The things that
> > make sense to one person can seem strange to another.
> >
> > I'm not sure I quite understand the motivation for locking around access
> > to the connections, sites, and the finding of the appropriate resource.
> > Can you explain?  You might be able to describe a case where two
> > HTTPConnections try to remove themselves simultaneously (my hunch is
> > that the ST process model handles this for us), but I can't think of any
> > where they'd be added simultaneously.  The only sender of #addConnection
> > is #interactWithNewConnectionOver:, and this is all done from the single
> > loop inside of HTTPServer.  I see no race conditions there.  Sites are
> > only added and removed by the site registry -- do you envision sites
> > being added and removed from multiple threads?  Perhaps you have a
> > system where two administrators will be working on a site hierarchy at
> > the same time?  And why is it needed around the #getResourceFor... ?
> >
> > I like the fact that your code closes the listening socket when the
> > server is stopped.  This makes good sense to me, and it will probably
> > mean that you don't need to set the soReuseaddr option.  I think we
> > should write this up in a proposal message, too.  Janko, I'll do the
> > proposal to rename the SiteIdentifier messages/vars, and I'll let you do
> > this one.  :)
> >
> > HTTPResponse:
> > -----
> > *Behavior: #printOn: added, which dumps the status of the response (e.g.
> > "HTTP/1.1 200 OK").   Extracted server string into its own message
> > #serverIntroduction) and changed to use a dynamic version (Swazoo
> > version).
> >
> > I like your printOn: method -- it'd be handy for debugging.  I don't
> > think you need a CR after it, though.  If another object needs CRs
> > (because it's printing a bunch of these), it should add them itself.
> >
> > The method HTTPResponse class>>#new that you've added is redundant,
> > since it inherits the exact same thing from HTTPMessage.
> >
> > I also like the idea of having a dynamic version number for Swazoo.  We
> > also need to make sure that the format of our version number matches the
> > HTTP RFCs.
> >
> > As a side note, the class comment in the 0.9.1 parcel says "Copyright
> > (c) Kazuki Yasumatsu, 1995...".  This was a little surprising.  :)
> > Perhaps he wrote a class by the same name for SmallWalker, but this
> > class particular class was written for Swazoo.
> >
> > HTTPRequest:
> > -----
> > *State: renamed 2 inst vars (ip -> serverAddress, peer -> peerAddress)
> >
> > I want to rename these two variables, too.. but I'm not quite convinced
> > that these are the best names.   What do others think?
> >
> > As a side note, the printString in this object is really ugly.  I think
> > that #printOn: and friends should be used for debugging purposes.. what
> > do you want to see when inspecting this object?  If you want to have a
> > nice printer for a logging facility, that should go in a different
> > method.
> >
> > SiteRegistry / Swazoo
> > -----
> > State: no more Singleton class var.  Instead, the singleton is stored in
> > a global variable.  Sites are started and stopped at appropriate times
> > during snapshot, image shutdown, and image startup.
> >
> > I have little to add to the discussions about class names, except that
> > it's worth noting that the three most significant classes (as far as
> > "learning the system" goes) are in a class category called
> > "Swazoo": SiteRegistry, HTTPServer, and HTTPConnection.  That alone
> > should give people a good hint about where to start.
> >
> > I'm not sure what to think about the starting/stopping servers during
> > snapshot.  During development, this might be handy.  During deployment,
> > is it needed?  For Signal Ground, I made a headless image whose
> > hlstrc.st file contains one line: SiteRegistry
> > configureFrom: 'sites.cnf'.  That starts it up when the image starts.  I
> > have noticed that it doesn't seem to release the socket quite right when
> > I kill the "visual" process, but I'm not sure if ObjectMemory sends out
> > its updates when the VM is killed via kill -15.  :)  What do others
> > think about this?
> >
> > For now, keeping the Singleton in a global variable seems like another
> > YAGNI.  When we have a need for this kind of behavior, we'll add it.
> >
> > Site
> > ----
> > *Behavior: #start and #stop added.  Can tell you if it's started.
> > Starts and stops itself by communicating with the registry.
> >
> > Janko, we have a mechanism that lets you "turn off" a site for a while
> > -- its called isEnabled.  Can we use this instead of the site
> > #start/stop?
> >
> > Character & CharacterArray
> > -----
> > *Behavior: changes to #decodedHTTP.
> >
> > I can see how the original version would break if the data was
> > truncated.. but I'm not sure about the way you attempt to solve this.
> > Perhaps you should write a test case or two -- so that I can see what
> > you expect as results from some truncated input.  Write this up as a
> > proposal, too, and send it to us.  :)
> >
> > ------------
> >
> > Whew!
> >
> > Janko, please let me know if I've missed something.  I apologize to
> > everybody for this monstrosity of a post.. but I think it's important
> > that we look at these things carefully.
> >
> > Ken
> >
> > ----
> > Ken Treis
> > [hidden email]
> >
> > _______________________________________________
> > Swazoo-devel mailing list
> > [hidden email]
> > http://lists.sourceforge.net/mailman/listinfo/swazoo-devel
>
> --
> Janko Mivsek
> Systems Architect
> EraNova d.o.o.
> Pod hribom 55
> SI-1000 Ljubljana
> Slovenia
> phone: +386 1 5816 232
> fax: +386 1 5816 231
> [hidden email]
> www.eranova.si
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> http://lists.sourceforge.net/mailman/listinfo/swazoo-devel

> At 03:50 PM 10/1/00 -0700, Ken Treis wrote:
> [snip]
> >One downside of CVST (at present) are that a Dolphin version isn't done
> >yet (it's "in the works", according to the project page).  The VW3 and
> >Squeak versions apparently work well.
>
> Has Swazoo been ported to Squeak? I didn't see it at SF. If it has been
> ported, and someone will send me the sources, I can basically have
> swazoo.org up immediately. I was planning on spending next week porting
> swazoo to squeak so we'd have it at OOPSLA, so if the above was just a
> typo, I'd still be willing to do the port.
>
> I've brought up swazoo.org under VWNC3.1 on my daily-use NT box, but this
> machine is old and lacks sufficient memory for me to leave the site up and
> still use it for everything else I do. No big deal: i've got a linux box i
> use for hosting. The trick there is that I'm not really a VW user, so i've
> been waiting for a squeak port (by myself or someone else) before i move
> the site over to my linux box. So...
>
> while i'm here, i suppose i should comment on some of the topics brought up
> on the list...
>
> [SourceForge] don't like it. i've done all my interaction with SF through
> their web interface, so i can't comment on the CVS interface. the website
> is *slow* (and i'm running on a 640Kps DSL line) and not at all intuitive.
> there have been times where i've gone to the site and totally failed to
> find the source files. not a good thing.
>
> [UnitTests] i think we are all in agreement [with Janko, perhaps, only
> grudgingly in agreement :)] that the unit tests are a Good Thing. But
> Janko's frustrations points to an issue that i think we need to address
> explicitly: not everyone has XP or unit testing experience. If swazoo is to
> attract a larger audience and more developers, then chances are people new
> to the project will also be new to unit tests. So what do we do? In the
> absence of any good, hands on, unit testing books and/or tutorials, (i'm
> only aware of one small piece--anyone else got any pointers?) I think we
> need to develop guidelines and a tutorial of our own on unit testing. The
> guidelines should layout exactly what is expected in terms of base code/fix
> submissions, what level of testing is/is not acceptable, etc. I am of the
> opinion that we should take a rather hard line about having to submit tests
> with new code, but we should also be quick to help/mentor developers that
> want to contribute but are not yet up to speed on unit testing.
>
> [SiteRegistry/Swazoo] i can appreciate the need for clarity and
> intuitiveness, but my gut tells me this is a place where a good page of
> documentation would do more than any amount of renaming could do. After
> all, when XP echews documentation, it is eschewing *code* documention, not
> "How to Install", "Getting Started With ...", ie usage documentation. And
> we need usage documentation not just for how to start swazoo, but also for
> the configuration files.
>
> [Wiki] Ken? Janko? as soon as i can bring up swazoo in squeak on linux, i'm
> going to want to add a wiki to the site.
>
> [Logo] i've attached a logo that i did with the help of a friend. it is not
> *exactly* what i had in mind, but...
>
> [OOPSLA] i'm flying into Minneapolis on Saturday with my wife. We'll spend
> Sat and Sun doing the tourist thing (and trying to get into the A Prarie
> Home Companion broadcast Saturday night). My wife flies back to Denver
> early Monday morning and I will be in OOPSLA mode from there on out. I'm
> staying in the Hyatt.
>
> david
>
>   --------------------------------------------------------------------------------
>                   Name: swazoo3.GIF
>    swazoo3.GIF    Type: GIF Image (image/gif)
>               Encoding: base64
>
>   --------------------------------------------------------------------------------
>
> --
> David Farber
> [hidden email]

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> Ken Treis
> Sent: Sunday, October 01, 2000 5:50 PM
> To: Swazoo-Devel Mailing List
> Subject: [Swazoo-devel] Taking Swazoo Forward [Long]
>
>
> Hi all,
>
> I've finally had a little bit of time to look at the 0.9.1
> code.  First
> of all, I want to thank Janko for all of the work he's done on Swazoo
> recently.  In addition to the coding work he's done, his activity has
> given us all a little push to get back into the Swazoo groove.
>
> I also wanted to ask everyone how well SourceForge is working.  Are
> people able to use the parcels now?  If it's a paoin to use,
> it'll deter
> people from working collaboratively on Swazoo.  That's bad.
>
> Personally, I find use of SourceForge (and CVS) for Swazoo development
> under Linux to be so-so.  If Smalltalk mapped into flat files more
> easily, perhaps it'd be better.  If I'm the only one checking
> things in,
> then it's fine.. but it can become a pain when we have several people
> working on the project.  I'd like our team to take a good
> look at CVST,
> since it seems to be coming along quite nicely (they're calling it
> "beta" now, and they're using it for CVST development).  Does anybody
> else think this would be a good idea?
>
> One downside of CVST (at present) are that a Dolphin version
> isn't done
> yet (it's "in the works", according to the project page).  The VW3 and
> Squeak versions apparently work well.
>
> One of the main reasons that I'm bringing this up is that I've noticed
> us getting a little out of sync in our development.  Before Janko's
> changes, we had a set of chunk files that were up to date.
> We also had
> some VisualWorks 3.x parcels that were up to date, along with some 5i
> parcels that were a little outdated IIRC -- and a Dolphin port based
> on our somewhat outdated camp0.9 parcels.  Janko's changes
> are based on
> the camp0.9 parcels, too, so now we have a real maintenance
> nightmare on
> our hands.  That's not Janko's fault; it'd be almost as bad
> even if he'd
> based his changes on the latest-and-greatest parcels from SourceForge.
>
> The real challenge comes in merging Janko's changes (where
> appropriate)
> into the current Swazoo base -- and it turns out that there
> are a number
> of changes.  During CampST, the integration team was able to, well...
> integrate... the changes made by all other teams very quickly.  The
> situation is a little different now, and everybody needs to take some
> _personal_ responsibility for keeping things well-integrated, as I'm
> sure everyone knows.  That means that, if at all possible, changes to
> the code should be made in cooperation with the rest of the Swazoo
> team.  It'll cause headaches if anybody goes off into a
> corner and codes
> for more than a couple of days.
>
> With that said, I'd like to propose a bit of a "Swazoo etiquette".
> Here's how it goes.  If you see something in Swazoo that you'd like to
> change, send an email to the list.  Tag its subject with [PROP] (for
> "proposal").  Proposals should be concrete, quantifiable, and testable
> -- much like an XP story card.  Perhaps a proposal could even show a
> SUnit code snippet -- if you want quick approval from the other team
> members, this would be smart.  :)
>
> Everyone who receives a proposal message and cares about what
> goes into
> Swazoo should read these messages as soon as they can.  Replies to
> proposals should be technical.  We can discuss proposals, propose
> alternatives (if they exist), and then somebody can take
> responsibility
> for the change.
>
> Obviously, we can't do this for everything (e.g., "can I please add a
> cascade to the messages in HTTPServer>>#getAndDispatchMessages?").
> We're all decent developers, and we can use our best judgement here.
> But, when we're talking about adding or removing capabilities, fixing
> bugs, etc., I think it's important that we find the best way of
> accomplishing the task.
>
> Once again, the tests are crucial to integration.  I don't
> mind the idea
> of having tests in a separate parcel / CVS module -- it might make
> deployment a little simpler.  I think this would be easy to
> manage using
> CVST.
>
> No matter what direction we go for future code control (or future
> etiquette), we still have a bit of a problem now.  We have Janko's
> changes, based on camp0.9, and we need to figure out (a) which ones we
> want to keep just as they are and (b) which ones we want to
> borrow ideas
> from while creating a system that everybody likes.  From that
> perspective, here's my take.  I'll go through on a class by
> class basis,
> trying to pick out what the intent behind the changes is:
>
> HTTPConnection
> -----
> *Behavior: Added capability to keep timestamps for creation
> of the class
> and the time at which the last request was processed.  Added
> capability
> to run the get/send message loop at different priorities.  The
> connection now hangs onto the peer address rather than
> setting it in the
> newly created HTTPMessage.  Various methods renamed.
> *State: added 3 inst vars (timestamps, peerAddress, priority), renamed
> one (loop -> serveLoop).
>
> Janko has mentioned that these are for a future priority-downgrading
> algorithm.  Janko, please correct me if I'm wrong.  There are
> no senders
> of #timestamps, #lastRequestTimestamp, or #createdTimestamp in the
> parcel, so I can't tell what they're used for (if anything yet).  The
> same goes for the priorities.  Have you implemented this algorithm, or
> is it simply being planned?
>
> If the algorithm hasn't been implemented yet, and you feel that it is
> necessary, then you should make your case in a [Prop]osal --
> algorithms
> can be tested nicely with SUnit.  Until then, I'd say "you
> aren't gonna
> need it" (YAGNI, from XP).
>
> For some of the method renaming, can we discuss this on the list?
>
> HeaderField
> -----
> *Behavior: #trimBlanks moved out of String and into this class as
> #trimBlanks:.
>
> Some subclasses still send #trimBlanks to the string, and
> HTTPPost uses
> #trimBlanks when reading itself off of a stream.  Added #printString
> which returns the field's value.
>
> As far as #trimBlanks goes, I'm somewhat split on this one --
> part of me
> thinks, "Do it in a more portable, less conflict-causing
> way".. that is,
> define it somewhere in one of our classes.  The other part of me says,
> "do it right.  Once and only once."  What do others think?
>
> For the printString, why is just the value printed?
>
> CompositeResource:
> -----
> *Behavior: added #includesResource: testing method.  This is
> used by the
> HTTPServer when adding a site to make sure it doesn't add the site
> twice.
>
> I'm not quite sure why we need to make sure of this... Janko, can you
> please elaborate?  Perhaps somebody has put the same site into the
> sites.cnf file twice?  Are there any other conditions where
> this causes
> a problem?
>
> SiteIdentifier:
> -----
> *State: renamed 2 inst vars (ip -> address, host ->
> hostname).  Creation
> method changed from #ip:port:host: to #hostname:address:port:.
>
> I like these two renames -- they're a little more clear than the
> previous names.  I also like having hostname be the first part of the
> hostname:address:port: creation method, because it seems more logical
> that way.  We should write this up as a proposal.
>
> HTTPServer:
> -----
> *Behavior: various method renames.  Added lock around #addSite:,
> #removeSite: #getResourceFor:using:, #addConnection:,
> #removeConnection.  Split up #isServing into two parts (serveLoop is
> active and socket is active).  Listening socket is closed on server
> stop.  Various socket options set (soReuseaddr).
> *State: added 2 inst vars (socket, lock).
>
> IMHO, method renames should be discussed on the list.  The things that
> make sense to one person can seem strange to another.
>
> I'm not sure I quite understand the motivation for locking
> around access
> to the connections, sites, and the finding of the appropriate
> resource.
> Can you explain?  You might be able to describe a case where two
> HTTPConnections try to remove themselves simultaneously (my hunch is
> that the ST process model handles this for us), but I can't
> think of any
> where they'd be added simultaneously.  The only sender of
> #addConnection
> is #interactWithNewConnectionOver:, and this is all done from
> the single
> loop inside of HTTPServer.  I see no race conditions there.  Sites are
> only added and removed by the site registry -- do you envision sites
> being added and removed from multiple threads?  Perhaps you have a
> system where two administrators will be working on a site hierarchy at
> the same time?  And why is it needed around the #getResourceFor... ?
>
> I like the fact that your code closes the listening socket when the
> server is stopped.  This makes good sense to me, and it will probably
> mean that you don't need to set the soReuseaddr option.  I think we
> should write this up in a proposal message, too.  Janko, I'll do the
> proposal to rename the SiteIdentifier messages/vars, and I'll
> let you do
> this one.  :)
>
> HTTPResponse:
> -----
> *Behavior: #printOn: added, which dumps the status of the
> response (e.g.
> "HTTP/1.1 200 OK").   Extracted server string into its own message
> #serverIntroduction) and changed to use a dynamic version (Swazoo
> version).
>
> I like your printOn: method -- it'd be handy for debugging.  I don't
> think you need a CR after it, though.  If another object needs CRs
> (because it's printing a bunch of these), it should add them itself.
>
> The method HTTPResponse class>>#new that you've added is redundant,
> since it inherits the exact same thing from HTTPMessage.
>
> I also like the idea of having a dynamic version number for
> Swazoo.  We
> also need to make sure that the format of our version number
> matches the
> HTTP RFCs.
>
> As a side note, the class comment in the 0.9.1 parcel says "Copyright
> (c) Kazuki Yasumatsu, 1995...".  This was a little surprising.  :)
> Perhaps he wrote a class by the same name for SmallWalker, but this
> class particular class was written for Swazoo.
>
> HTTPRequest:
> -----
> *State: renamed 2 inst vars (ip -> serverAddress, peer -> peerAddress)
>
> I want to rename these two variables, too.. but I'm not quite
> convinced
> that these are the best names.   What do others think?
>
> As a side note, the printString in this object is really
> ugly.  I think
> that #printOn: and friends should be used for debugging
> purposes.. what
> do you want to see when inspecting this object?  If you want to have a
> nice printer for a logging facility, that should go in a different
> method.
>
> SiteRegistry / Swazoo
> -----
> State: no more Singleton class var.  Instead, the singleton
> is stored in
> a global variable.  Sites are started and stopped at appropriate times
> during snapshot, image shutdown, and image startup.
>
> I have little to add to the discussions about class names, except that
> it's worth noting that the three most significant classes (as far as
> "learning the system" goes) are in a class category called
> "Swazoo": SiteRegistry, HTTPServer, and HTTPConnection.  That alone
> should give people a good hint about where to start.
>
> I'm not sure what to think about the starting/stopping servers during
> snapshot.  During development, this might be handy.  During
> deployment,
> is it needed?  For Signal Ground, I made a headless image whose
> hlstrc.st file contains one line: SiteRegistry
> configureFrom: 'sites.cnf'.  That starts it up when the image
> starts.  I
> have noticed that it doesn't seem to release the socket quite
> right when
> I kill the "visual" process, but I'm not sure if ObjectMemory
> sends out
> its updates when the VM is killed via kill -15.  :)  What do others
> think about this?
>
> For now, keeping the Singleton in a global variable seems like another
> YAGNI.  When we have a need for this kind of behavior, we'll add it.
>
> Site
> ----
> *Behavior: #start and #stop added.  Can tell you if it's started.
> Starts and stops itself by communicating with the registry.
>
> Janko, we have a mechanism that lets you "turn off" a site for a while
> -- its called isEnabled.  Can we use this instead of the site
> #start/stop?
>
> Character & CharacterArray
> -----
> *Behavior: changes to #decodedHTTP.
>
> I can see how the original version would break if the data was
> truncated.. but I'm not sure about the way you attempt to solve this.
> Perhaps you should write a test case or two -- so that I can see what
> you expect as results from some truncated input.  Write this up as a
> proposal, too, and send it to us.  :)
>
> ------------
>
> Whew!
>
> Janko, please let me know if I've missed something.  I apologize to
> everybody for this monstrosity of a post.. but I think it's important
> that we look at these things carefully.
>
>
> Ken
>
> ----
> Ken Treis
> [hidden email]
>
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> http://lists.sourceforge.net/mailman/listinfo/swazoo-devel
>

> The real challenge comes in merging Janko's changes (where appropriate)
> into the current Swazoo base -- and it turns out that there are a number
> of changes.  During CampST, the integration team was able to, well...
> integrate... the changes made by all other teams very quickly.  The
> situation is a little different now, and everybody needs to take some
> _personal_ responsibility for keeping things well-integrated, as I'm
> sure everyone knows.  That means that, if at all possible, changes to
> the code should be made in cooperation with the rest of the Swazoo
> team.  It'll cause headaches if anybody goes off into a corner and codes
> for more than a couple of days.

> Hi,
>
> Let we discuss in this thread about rules of collaboration
> on our project.
>
> Ken Treis wrote:
> > One of the main reasons that I'm bringing this up is that I've noticed
> > us getting a little out of sync in our development.  Before Janko's
> > changes, we had a set of chunk files that were up to date.  We also had
> > some VisualWorks 3.x parcels that were up to date, along with some 5i
> > parcels that were a little outdated IIRC -- and a Dolphin port based
> > on our somewhat outdated camp0.9 parcels.  Janko's changes are based on
> > the camp0.9 parcels, too, so now we have a real maintenance nightmare on
> > our hands.  That's not Janko's fault; it'd be almost as bad even if he'd
> > based his changes on the latest-and-greatest parcels from SourceForge.
>
> And here are first rule proposals :)
>
> 1. Means of communication: This mailing list is only channel
> to communicate between members of a project. Private
> messages should be avoided if possible IMHO.
> 2. Code exchange: all code exchange between project members
> goes through this mailing list. That's only possible way
> that all of us will be informed about what's going on (until
> CVS is unusable)
> 3. versions and version numbering: let we have stable
> versions and beta versions. Version numbering goes like
> 0.9.1 beta1.
> 4. Librarian: Joseph is our librarian, he is responsible for
> releasing a new stable versions (Joe, is that still true?)
> 5. Announcements of stable releases: On SourceForge File
> Releases, on c.l.s, on mailing list for ST dialects
> released, on this mailing mailing list of course :), on
> CampSmalltalk Wiki ...
>
> > The real challenge comes in merging Janko's changes (where appropriate)
> > into the current Swazoo base -- and it turns out that there are a number
> > of changes.  During CampST, the integration team was able to, well...
> > integrate... the changes made by all other teams very quickly.  The
> > situation is a little different now, and everybody needs to take some
> > _personal_ responsibility for keeping things well-integrated, as I'm
> > sure everyone knows.  That means that, if at all possible, changes to
> > the code should be made in cooperation with the rest of the Swazoo
> > team.  It'll cause headaches if anybody goes off into a corner and codes
> > for more than a couple of days.
>
> I agree with you. Problem is only, how can we develop in a
> limited time all of us have and be still productive. And
> there is also a time difference between EU and US, therefore
> one day goes for every question/answer cycle.
>
> I know for myself that when I find a time to code something,
> I code a lot, I'm thinking only about a problem I'm solving
> and I'm doing this alone. Every question I have I solve by
> myself first, then I ask someone else to confirm my
> solution. This is my way to be as productive as possible in
> a short time I usually have. But this is not a teamwork ...
>
> Therefore I propose that everyone first announce here
> attention to make some changes. After a short discussion,
> let say a day or two, he made those changes by himself and
> completely. Then he post changes to us and another round of
> discussions goes around. Author of changes then refactor his
> work to be in line with result of discussions.
>
> Let we use online voting for resolution of some dilemmas
> also. Has SourceForge voting?
>
> Ok, it's a midnight here, let me continue tomorrow.
>
> Best regards
> Janko
>
>
>
> --
> Janko Mivsek
> Systems Architect
> EraNova d.o.o.
> Pod hribom 55
> SI-1000 Ljubljana
> Slovenia
> phone: +386 1 5816 232
> fax: +386 1 5816 231
> [hidden email]
> www.eranova.si
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> http://lists.sourceforge.net/mailman/listinfo/swazoo-devel