Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Future of Squeak, and outsider's view

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

43 messages Options

123

Eliot Miranda-2

Re: [squeak-dev] Re: Future of Squeak, and outsider's view

On Wed, Jul 1, 2009 at 10:12 AM, Stephen Pair <[hidden email]> wrote:

On Wed, Jul 1, 2009 at 12:18 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 6:15 PM, Stephen Pair <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <[hidden email]> wrote:

I can see a potential need in cases where a body of code is designed to interface with some already present service (for example, a phone dialer application designed to use an AddressBook service). But, in such a system, you wouldn't want to allow monkey patching anyway out of security concerns (if you could override the AddressBook interface, your code could potentially access information that the owner didn't want your code to access).

But how do you override your own AddressBook? Bringing a new one into existence is one thing, but modifying your fully-populated one implemented by someone else is another thing altogether. If the system is so architected then it is presumably trivial to create a new instance, move the data across and replace the old with the new. But if the system isn't (e.g. for security or ip concerns) then you can't. But these issues operate at a higher level than the language/module/update level right? The issues with monkey patching are to do with keeping software maintainable and comprehensible to software authors. The issues of mutable extensible systems also involve their users, and that's more than I can think about right now :)

Overriding your own AddressBook would be a problem of loading in new code and migrating the instances (pretty much like software works today where you load a new version of an application and it has to update your existing database(s)).

That's a fine scheme. My point is that unless the system is so architected you can't necessarily do that.

LoL...well, of course...if the problem were already solved, there would be no point in contemplating possible solutions.

Look at the iPhone for example; there are lots of restrictions on what a user can accomplish and there is software therein to detect attempts to hack around these restrictions and break things like software update when you try and update a hacked phone. So your model only works in an architecture which supports it. Since Newspeak doesn't encompass a complete device architecture it can't provide an update schema for it. Expecting a language to address this is IMO a category error.

Didn't someone once say that the operating system is where you resolve all of the inadequacies of your language (or something to that effect)? ;)

When one starts talking about for example a Smalltalk system running on bare hardware (e.g. Squeak NOS) then the system can encompass the entirety. So we should first try and evolve Newspeak to NewspeakNOS and ten we can see how an evolved NewspeakNOS would address these update issues.

I don't think you need to go to such lengths to either show that such a scheme would work, or to get use out of it if it does. Regarding your iPhone example, it takes the discussion beyond the realm of that which we have control and into the realm of interfacing with legacy systems in which none of these kinds of issues have been considered or addressed. Take and example of upgrading the AddressBook on the iPhone platform (where it's a third party tool over which you have no control other than to upgrade it) while having it still work with say a custom Dialer app that you wrote. You are free to upgrade either of them independently so long as they both support a common interface. If the interface were version controlled, you can deal with this problem in a pretty rational manner for an end user (when you go to the AppStore and try to upgrade the AddressBook app, it could alert you that "this new version of the AddressBook no longer supports version 1 of the AddressBook API and since we see that you have a registered dependency form some Dialer app on version 1.0, we can pretty much guarantee that it's going to break your Dialer app, are you sure you want to do this?" You could then independently upgrade the Dialer app.

To bring this back to monkey patching...no, you cannot monkey patch the AddressBook API, but you can create a new version of some framework (with as many customizations as you desire) for use in your Dialer app while the, while the AddressBook continues to use some other version of that very same framework concurrently. Of course, Cocoa is not going to support this kind of thing (at least not today), but it doesn't preclude apps in some other language that has Newspeak style modularization from doing this (regardless of whether it's running on bare metal or not).

I think I've run out of steam on this topic for now.

Hi Stephen,

apologies for apparently being obstructive. I was just trying to properly frame the discussion. I want to separate linguistic from system issues. Your first question was an excellent one and asked if linguistic mechanisms could resolve the issue and I said why I thought not. I didn't realise you were shifting ground to propose solutions and thought you were still discussing linguistic mechanisms. Apologies. Please don't run out of steam because I'm not going with the flow. I hope I get where you're aiming at now.

Could you extend your scenario with the potential for malware to attempt to patch the AddressBook and suggest ways one can legitimately patch the AddressBook and at the same time protect it from unwarranted modification?

- Stephen

Stephen Pair

Re: [squeak-dev] Re: Future of Squeak, and outsider's view

On Wed, Jul 1, 2009 at 1:59 PM, Eliot Miranda <[hidden email]> wrote:

On Wed, Jul 1, 2009 at 10:12 AM, Stephen Pair <[hidden email]> wrote:

On Wed, Jul 1, 2009 at 12:18 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 6:15 PM, Stephen Pair <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <[hidden email]> wrote:

I can see a potential need in cases where a body of code is designed to interface with some already present service (for example, a phone dialer application designed to use an AddressBook service). But, in such a system, you wouldn't want to allow monkey patching anyway out of security concerns (if you could override the AddressBook interface, your code could potentially access information that the owner didn't want your code to access).

But how do you override your own AddressBook? Bringing a new one into existence is one thing, but modifying your fully-populated one implemented by someone else is another thing altogether. If the system is so architected then it is presumably trivial to create a new instance, move the data across and replace the old with the new. But if the system isn't (e.g. for security or ip concerns) then you can't. But these issues operate at a higher level than the language/module/update level right? The issues with monkey patching are to do with keeping software maintainable and comprehensible to software authors. The issues of mutable extensible systems also involve their users, and that's more than I can think about right now :)

Overriding your own AddressBook would be a problem of loading in new code and migrating the instances (pretty much like software works today where you load a new version of an application and it has to update your existing database(s)).

That's a fine scheme.  My point is that unless the system is so architected you can't necessarily do that.

LoL...well, of course...if the problem were already solved, there would be no point in contemplating possible solutions.

  Look at the iPhone for example; there are lots of restrictions on what a user can accomplish and there is software therein to detect attempts to hack around these restrictions and break things like software update when you try and update a hacked phone. So your model only works in an architecture which supports it. Since Newspeak doesn't encompass a complete device architecture it can't provide an update schema for it. Expecting a language to address this is IMO a category error.

Didn't someone once say that the operating system is where you resolve all of the inadequacies of your language (or something to that effect)? ;)

When one starts talking about for example a Smalltalk system running on bare hardware (e.g. Squeak NOS) then the system can encompass the entirety. So we should first try and evolve Newspeak to NewspeakNOS and ten we can see how an evolved NewspeakNOS would address these update issues.

I don't think you need to go to such lengths to either show that such a scheme would work, or to get use out of it if it does. Regarding your iPhone example, it takes the discussion beyond the realm of that which we have control and into the realm of interfacing with legacy systems in which none of these kinds of issues have been considered or addressed. Take and example of upgrading the AddressBook on the iPhone platform (where it's a third party tool over which you have no control other than to upgrade it) while having it still work with say a custom Dialer app that you wrote. You are free to upgrade either of them independently so long as they both support a common interface. If the interface were version controlled, you can deal with this problem in a pretty rational manner for an end user (when you go to the AppStore and try to upgrade the AddressBook app, it could alert you that "this new version of the AddressBook no longer supports version 1 of the AddressBook API and since we see that you have a registered dependency form some Dialer app on version 1.0, we can pretty much guarantee that it's going to break your Dialer app, are you sure you want to do this?" You could then independently upgrade the Dialer app.

To bring this back to monkey patching...no, you cannot monkey patch the AddressBook API, but you can create a new version of some framework (with as many customizations as you desire) for use in your Dialer app while the, while the AddressBook continues to use some other version of that very same framework concurrently. Of course, Cocoa is not going to support this kind of thing (at least not today), but it doesn't preclude apps in some other language that has Newspeak style modularization from doing this (regardless of whether it's running on bare metal or not).

I think I've run out of steam on this topic for now.

Hi Stephen,

   apologies for apparently being obstructive. I was just trying to properly frame the discussion. I want to separate linguistic from system issues. Your first question was an excellent one and asked if linguistic mechanisms could resolve the issue and I said why I thought not. I didn't realise you were shifting ground to propose solutions and thought you were still discussing linguistic mechanisms. Apologies. Please don't run out of steam because I'm not going with the flow. I hope I get where you're aiming at now.

Could you extend your scenario with the potential for malware to attempt to patch the AddressBook and suggest ways one can legitimately patch the AddressBook and at the same time protect it from unwarranted modification?

Well, when you download the malware code, instantiate it and give it a handle to your AddressBook interface, as long as that interface doesn't let you do reflective things (like adding new methods) and doesn't let you do other destructive or undesirable things, then no matter how nefariously intentioned the malware is, it won't be able to do anything that you didn't explicitly give it the ability to do by exposing capability. This is what E is all about isn't it? And part of what Newspeak aims to address as well.

To legitimately patch the AddressBook, and do it in safe(ish) manner (I believe at some level, you have to have trust...after all, you trusted the original AddressBook code with your data) you would expose access to completely read (but not write) your address book objects...you would not expose access to the outside world...this new code would then migrate your data and setup the new address book code...you would then test out the new address book, and when, to you satisfaction it is handling you data in a responsible manner, you would expose any additional capabilities the address book needs (for example, send a vCard over bluetooth), then you would redirect your address book interfaces to the new code and data (you would need some means of forcing active clients off the old AddressBook implementation and onto the new).

I imagine much of the manual and careful steps above could be fully automated if you really trust the publisher of the code (so trust networks might be relevant). But, the you are still making a high level decision regarding to what degree you trust a given bit of code. In both cases, you are exposing only the capability that you expect is needed and you are holding back access to facilities that would enable the foreign code to do something it's not supposed to do.

(btw, you've alluded to some of Newspeak's synchronization plans, I'm not familiar with those (not sure if they've written extensively about those plans yet). So, they might have some good ideas around this stuff that I'm not bringing to this discussion because I haven't read up on it)

- Stephen

Eliot Miranda-2

Re: [squeak-dev] Re: Future of Squeak, and outsider's view

In reply to this post by Juan Vuletich-4

On Wed, Jul 1, 2009 at 6:08 AM, Juan Vuletich <[hidden email]> wrote:

Eliot Miranda wrote:

On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <[hidden email] <mailto:[hidden email]>> wrote:

...

I really fail to see how it would make any difference whatsoever
if extension methods are in multiple packages or not. In either
case you are *completely* screwed if you have multiple packages
trying to extend the same method. Seriously, has there ever been a
situation where that actually works? (my personal preference is
actually that MC should blow up straight into your face if you try
to change a method that's in an extension category already, but
that's just me - I generally avoid extensions like the plague)

I don't avoid extensions, and personally feel extensions are a core part of building frameworks. If objects are to interact they must provide protocol to support that interaction. In adding a new framework to an existing system this means extending existing objects so that they can interact with the new framework. Yes, one can do this badly, but there are lots of examples where this makes sense.

As far as patching, we've had this conversation before. I agree that a well-designed system will provide extension mechanisms that make patching unnecessary.

And later...

Gilad is virulently against monkey-patching and so there is no support for extensions in Newspeak modules...

Extension methods are useful, but can be dangerous. Problems will arise if a module modifies the behavior that is expected by the base system or by other modules that do not include us as a prerequisite.

Things a module should not be able to do to existing classes (defined in the base system or in other modules)
- patching: modify existing methods, including any extensions done by other modules
- add new methods that redefine inherited behavior (I mean, a method not already implemented but inherited)
- delete any method

Things a module should be able to do:
- extend existing classes with new methods that do not affect the base system or any other module that does not include us as a prerequisite

An easy way to ensure this is to require each module to define a prefix for its extension methods. The system must ensure that the prefixes are distinct for all modules, and that a prefix can be used only by its owning module to define new methods. The base system can not use any of those prefixes. A module can call a prefixed method only if it owns it, or it belongs to some other module that was declared as a prerequisite.

It is sort of cheap namespaces for methods (not for classes).

What do you think?

Hi Juan,

basically my experience leads me to disagree that one can't patch. I think one needs to patch. The difference is between the kind of package and how deep the change it needs to make is. if, like me, you're working on the compiler you *absolutely need* to patch existing base classes to install a new compiler unless the system was architected to have a new compiler in the first place. This is the tension. When the system is well-enough architected one can use pluggable schemes that have been provided to avoid base patches. But real systems don't have those facilities everywhere and only have those facilities in places where system designers have the foresight to provide them. But to modify a system by loading packages to get to a point where it is more pluggable you'll need to patch base classes. Chicken and egg. So I prefer the approach that provides absolute power (you can patch anything) and provides argumentation guidelines and examples that help people avoid using that absolute power unless they absolutely have to.

I think there's an analogy with become and thisContext. These two features are extremely powerful and can be horribly abused (along with MNU handlers :) ). But in practice they don't get horribly abused, except perhaps by people experimenting and learning. But think what the system would be like *without* become and thisContext. It would loose huge amounts of power. With power comes responsibility but without power there is impotence and apathy :)

Cheers,
Juan Vuletich

123