Smalltalk › Squeak › Squeak - Dev

Dan Ingalls' Environments package

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

J J-6

Dan Ingalls' Environments package

Anyone used Dan's Environments package: http://wiki.squeak.org/squeak/5611
?

_________________________________________________________________
Download Messenger. Join the im Initiative. Help make a difference today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07

K. K. Subramaniam

Re: Dan Ingalls' Environments package

On Tuesday 08 May 2007 12:47 am, J J wrote:
> Anyone used Dan's Environments package: http://wiki.squeak.org/squeak/5611

Is this still being pursued? I got 404-ed when I tried to follow the New
Modules ->Modules discussion list.

Regards .. Subbu

Michael van der Gulik-2

Re: Dan Ingalls' Environments package

In reply to this post by J J-6

On 5/8/07, J J <[hidden email]> wrote:

Anyone used Dan's Environments package: http://wiki.squeak.org/squeak/5611

I'm trying to solve all the same problems with my Namespaces package:

http://www.squeaksource.com/SecureSqueak.

You'll need to email me directly for installation directions. It's currently still in a state of flux.

Michael.

J J-6

Re: Dan Ingalls' Environments package

Ah thanks. I am actually looking around at all the different ways people do
this concept of "module/namespace" to see what the best possible solution
is. I would like something that is more advanced then just playing tricks
with the selectors and the tools, but not something that changes the
language substantially.

That is, I think the work you're doing is very good and interesting, but I'm
not yet convinced about locking smalltalk down to such a level. Perhaps
that is the way to go, we'll see, but one must keep in mind that there is a
slider bar: on one side is "user friendly-ness" and on the other side is
"security". The more secure you are, the less user friendly. The more user
friendly, the less secure. It is a tricky thing to balance properly, and
for the moment I consider the domain of the application developer, not the
language. But who knows, maybe you will change my mind. :)

>From: "Michael van der Gulik" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: Dan Ingalls' Environments package
>Date: Thu, 10 May 2007 11:16:12 +1200
>
>On 5/8/07, J J <[hidden email]> wrote:
>>
>>Anyone used Dan's Environments package: http://wiki.squeak.org/squeak/5611
>>
>
>I'm trying to solve all the same problems with my Namespaces package:
>
>http://www.squeaksource.com/SecureSqueak.
>
>You'll need to email me directly for installation directions. It's
>currently
>still in a state of flux.
>
>Michael.

>

_________________________________________________________________
Catch suspicious messages before you open themwith Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_protection_0507

Tony Garnock-Jones-2

Decentralized, Secure, Human-Meaningful: Choose Two (was Re: Dan Ingalls' Environments package)

J J wrote:
> Perhaps that is the way to go, we'll see, but one must keep in mind that
> there is a slider bar: on one side is "user friendly-ness" and on the
> other side is "security". The more secure you are, the less user
> friendly. The more user friendly, the less secure.

I'm not sure it's quite so binary.

There's an idea called "Zooko's Triangle",
http://en.wikipedia.org/wiki/Zooko's_triangle, that states that names
can be any *two* of

- human-meaningful/friendly/memorable
- decentralised
- secure/unique

but never all three at once.

The situation we have within a Squeak image today is a *centralised*
human-meaningful unique naming system: classes have unique names in a
central, system-wide directory.

The situation we have within the Squeak community at large is a little
different: a decentralised, human-meaningful, but *non-unique* naming
system, where anybody at all can build their own MyClass, completely
different to everybody else's.

Systems like Craig's naiad, if I understand correctly, are decentralised
and unique, and sacrifice a certain degree of human-meaningfulness. This
strikes me as the way to go, because tools can help bridge the gap to a
system just as easy to use as the current centralised class dictionary.

For an excellent introduction to the idea of "petnames",
locally-meaningful names for securely-unique keys, please see
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html

The "examples and near examples" section is particularly interesting -
it's easy to imagine Squeak's tooling slightly refactored to provide
outstanding support for a petname system for classes.

More references:

http://zooko.com/distnames.html
http://shirky.com/writings/domain_names.html

Regards,
Tony
--
[][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211
[][] LShift Ltd | Tel: +44 (0)20 7729 7060
[] [] http://www.lshift.net/ | Email: [hidden email]

Chris Muller-3

Re: Decentralized, Secure, Human-Meaningful: Choose Two (was Re: Dan Ingalls' Environments package)

For code-elements, I've always been interested in the idea of
maintaining human-meaningful names by "dodging" name collisions
dynamically. For the most part, prefixes combined with our desire for
slim images have carried us this far, but one should expect a
name-collision eventually. We can do what Java did, "use huge
prefixes" but then there's still the potential for a collision. When
that happens, why shouldn't a dynamic system dynamically adjust it?

This is just an idea for getting modules to co-exist in a Smalltalk
image, it is completely independent of module authentication..

On 5/11/07, Tony Garnock-Jones <[hidden email]> wrote:

> J J wrote:
> > Perhaps that is the way to go, we'll see, but one must keep in mind that
> > there is a slider bar: on one side is "user friendly-ness" and on the
> > other side is "security". The more secure you are, the less user
> > friendly. The more user friendly, the less secure.
>
> I'm not sure it's quite so binary.
>
> There's an idea called "Zooko's Triangle",
> http://en.wikipedia.org/wiki/Zooko's_triangle, that states that names
> can be any *two* of
>
> - human-meaningful/friendly/memorable
> - decentralised
> - secure/unique
>
> but never all three at once.
>
> The situation we have within a Squeak image today is a *centralised*
> human-meaningful unique naming system: classes have unique names in a
> central, system-wide directory.
>
> The situation we have within the Squeak community at large is a little
> different: a decentralised, human-meaningful, but *non-unique* naming
> system, where anybody at all can build their own MyClass, completely
> different to everybody else's.
>
> Systems like Craig's naiad, if I understand correctly, are decentralised
> and unique, and sacrifice a certain degree of human-meaningfulness. This
> strikes me as the way to go, because tools can help bridge the gap to a
> system just as easy to use as the current centralised class dictionary.
>
> For an excellent introduction to the idea of "petnames",
> locally-meaningful names for securely-unique keys, please see
> http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
>
> The "examples and near examples" section is particularly interesting -
> it's easy to imagine Squeak's tooling slightly refactored to provide
> outstanding support for a petname system for classes.
>
> More references:
>
> http://zooko.com/distnames.html
> http://shirky.com/writings/domain_names.html
>
> Regards,
> Tony
> --
> [][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211
> [][] LShift Ltd | Tel: +44 (0)20 7729 7060
> [] [] http://www.lshift.net/ | Email: [hidden email]
>
>

ccrraaiigg

Re: Decentralized, Secure, Human-Meaningful: Choose Two

In reply to this post by Tony Garnock-Jones-2

Hi Tony--

> Systems like Craig's Naiad, if I understand correctly, are
> decentralised and unique, and sacrifice a certain degree of
> human-meaningfulness.

Naiad distinguishes between name and identity (hence the name,
"Name And Identity Are Distinct"). It adds identity as a first-class
attribute to classes, and leaves the names alone. The identities are
decentralized and totally unmeaningful to humans, while the names are
just as meaningful as they ever were. The system can tell you name for a
particular identity, and vice-versa. The Zooko's Triangle dilemma is
solved by adding a level of indirection.

> This strikes me as the way to go, because tools can help bridge the
> gap to a system just as easy to use as the current centralised class
> dictionary.

Yes.

thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Lex Spoon-3

Re: Decentralized, Secure, Human-Meaningful: Choose Two (was Re: Dan Ingalls' Environments package)

In reply to this post by Chris Muller-3

"Chris Muller" <[hidden email]> writes:
> For code-elements, I've always been interested in the idea of
> maintaining human-meaningful names by "dodging" name collisions
> dynamically. For the most part, prefixes combined with our desire for
> slim images have carried us this far, but one should expect a
> name-collision eventually. We can do what Java did, "use huge
> prefixes" but then there's still the potential for a collision. When
> that happens, why shouldn't a dynamic system dynamically adjust it?

In practice, many Java developers are leaning away from using
DNS-based names, and instead simplying using a normal package name as
your prefix. Certainly I do so when I'm adrift in Java land.

Note that if your top-level package names collide, then you have
problems anyway. Your jar files are going to collide, and you will
have trouble registering on things like FreshMeat or SqueakMap. Thus,
to share a package publicly, you already need to come up with a unique
name, and you can then use that name in the code as well.

Which, by the way, Monticello already takes as a heuristic. It's just
one step further to treat categories as naming prefixes.

Overall, I find myself envious of Java's global naming scheme. Yes,
the DNS-based names are nonsense. Leaving that aside, though, the
Java system is simple, it works, and we could have it, but we don't.

The main argument I see against the Java system is for small Squeak
images. This might be a point of forking for Squeak: one way goes
towards miniature educational and experimental systems, while the
other leans towards serious software development.

Lex

Tony Garnock-Jones-2

Re: Decentralized, Secure, Human-Meaningful: Choose Two (was Re: Dan Ingalls' Environments package)

Lex Spoon wrote:
> Overall, I find myself envious of Java's global naming scheme. Yes,
> the DNS-based names are nonsense. Leaving that aside, though, the
> Java system is simple, it works, and we could have it, but we don't.

It *sort of* works - it still doesn't provide securely-unique names.
Decentralised - check; human-memorable - check; not so securely-unique,
in the limit.

OSGI is perhaps an interesting hackaround wrt naming issues.

Regards,
Tony