[Pharo-project] Splitting network package

Bill Schwab BSchwab at anest.ufl.edu
Thu Jan 8 23:00:06 EST 2009

No flame wars here.  I do not yet know enough about the URL/I classes,
but will gladly consider any good code.  I will reiterate that it would
be nice to get the cryptography guys involved (thinking of SSL in
particular) if possible.  Re complete replacement, as precedent, please
note Nile.  It is not in yet, but that is a stated goal, so I think you
will find that such things will be given serious consideration.

Now for something completely different - and what first grabbed my
attention.  You mentioned cherry picking changes.  I cannot really offer
any help just yet, except to note a couple of things that have been
useful in Dolphin.  The first is Ian Bartholomew's ChunkBrowser - it is
a fantastic tool and should be ported/recreated in Pharo if at all
possible.  Obviously we would respect Ian's licensing terms, provide
proper credit, etc.  Did I mention that it is a NICE thing to have? :)

I wrote and use a tool called Migrate for getting code out of one
Dolphin image and into another.  It has been sensitive to changes in the
packaging system, but the general idea is to build a list of the
currently installed packages and produce a script to load them into a
new image.  I added a concept of "safe" and "dangerous" loose methods. 
One might argue that only the dangerous methods (essentially overrides)
are needed - I'm too tired to figure out why I have two types<g>, but I
probably wrote it down somewhere.  Migrate also arranges to file out and
in those methods, but optionally on the in-side.

I realize none of this is useful now, but I would expect to create Pharo
versions of pieces that make sense in Pharo.  Making sense will also be
constrained in part by my level of use of Pharo over time.  I have a LOT
of Dolphin packages, so listing them in a sensible order is not a
trivial task.  I also hacked a few things that need to be reviewed when
changing to a new version, and found ways to keep track of that w/o
creating collisions  with the base system packages.  Feel free to run
with any ideas that seem helpful.


Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab at anest.ufl.edu
Tel: (352) 273-6785
FAX: (352) 392-7029

>>> m.rueger at acm.org 01/08/09 1:51 PM >>>
Hi all,

updated MIME, URI and File packages in inbox.

Some of the URI related changes are somewhat incomplete as I merged them

from a different context. Hopefully I didn't break anything though :-)

With merges like this it is really a problem that MC doesn't allow 
cherry picking changes...

The overall goal with the URI changes is to complete replace the current

Url implementation. We have done this quite successfully in Sophie and 
even more radically in the experimental ySqueak branch.

Suggesting to replace Url classes by URI was a sure way to get a flame 
war going on the Squeak dev list. So what is general opinion on this for



Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr

More information about the Pharo-dev mailing list