Taking Swazoo Forward [Long]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Taking Swazoo Forward [Long]

Ken Treis-4
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]


Reply | Threaded
Open this post in threaded view
|

Re: Taking Swazoo Forward [Long]

David Farber

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


--
David Farber
[hidden email]

swazoo3.GIF (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Taking Swazoo Forward

Janko Mivšek
In reply to this post by Ken Treis-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Taking Swazoo Forward

Joseph Bacanskas
Hi:

One way to start might be to show (if you have an internet link)
http://www.signalground.com/  which is built on Swazoo (and Hydrogen).  I think
that showing software from Camp running on the internet will suprise a lot of
people.

Janko Mivsek wrote:

> 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

--
Thanks!!

Joseph Bacanskas [|]

--- I use Smalltalk.  My amp goes to eleven.




Reply | Threaded
Open this post in threaded view
|

Re: Taking Swazoo Forward [Long]

Joseph Bacanskas
In reply to this post by David Farber
Hi:

LOVE THE LOGO!

I think you are mis-reading the post.  The CVST is partially working on Squeak, not
Swazoo.  So go to it!

There are a few resources available for XP/SUnit tests.  IMHO, the best examples are
the one's included with SUnit and Swazoo.  It sounds like we are coming to an
aggreement that we need something like:

A Swazoo-User-HOWTO
A Swazoo-Developer-HOWTO

Comments?

See you at OOPSLA!

David Farber wrote:

> 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]

--
Thanks!!

Joseph Bacanskas [|]

--- I use Smalltalk.  My amp goes to eleven.




Reply | Threaded
Open this post in threaded view
|

RE: Taking Swazoo Forward [Long]

Jerry Bell
In reply to this post by Ken Treis-4
I agree that keeping the code in sync across platforms may be a problem.
The Dolphin port is quite behind, but my free time situation should be
improving soon.  I'm planning to let the current changes to the VW parcels
settle, and then port those changes to Dolphin.

Still, there will still be some lag in propagating changes across platforms
unless we are able to figure out some way to isolate code that is completely
portable across platforms from code which isn't.  The lag probably won't be
too drastic, so it may not be worth the effort.  Also, it probably makes
sense to wait until a Squeak port has been completed, so that we have 3 data
points as to what bits aren't completely portable.

Other random information:  Dolphin 4 should be released sometime this month,
and it includes a package format which is CVS-friendly.  The Dolphin Swazoo
port runs fine on 4.0 beta 1 with no changes.

Does anyone have a potential date for the next Camp Smalltalk (after
OOPSLA)?  I'd love to attend, but I haven't been able to make it thus far.
Perhaps this time I'll be luckier.  Is a Swazoo presence planned for it?

Jerry Bell
[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
>


Reply | Threaded
Open this post in threaded view
|

Re: SourceForge troubles

Janko Mivšek
In reply to this post by Ken Treis-4
Hi all,

I will respond to Ken post in many posts in order that we
can discuss different topics separately.

Ken Treis wrote:

> 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.

I think that SourceForge is good for publicity but not very
handy for ST development (yet). I propose that we publish
the final versions on File section on a first page (to be
visible) and not on CVS.

> 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?

For me it seems that a mailing list with code attachments
will be the easiest and quickest thing to exchange the code.

Also it seems that the speed of this mailing list is also
problematic. I noticed that it took 2 days for one of my
posts to be ditributed to all of us. If this will happen
many times, then we must think of switching to better
mailing list also.

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

Reply | Threaded
Open this post in threaded view
|

Re: Swazoo etiquete

Janko Mivšek
In reply to this post by Ken Treis-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Swazoo etiquete

Joseph Bacanskas
Hi:

Just a quick comment, I respond at length later.  I would be happy to continue
my role as "librarian".

Janko Mivsek wrote:

> 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

--
Thanks!!

Joseph Bacanskas [|]

--- I use Smalltalk.  My amp goes to eleven.