Well, congrats! Hope you're having fun there. There is no urgency on our 
end so take your time to get settled :-)

Cheers,
   - Andreas

On 5/17/2010 12:15 PM, Dale Henrichs wrote:
> Andreas,
>
> Certainly ... GemStone has been acquired VMWare and today is my first day as a VMWare employee so things will be a little unsettled for the next day or so, but I will get something to you as soon as the decks get cleared...
>
> Dale
> ----- "Andreas Raab"<andreas.raab at gmx.de>  wrote:
>
> | Hi Dale -
> |
> | I completely understand your reasoning and I'm not criticizing it all.
> | I
> | would've done just the same to get initial adoption (and it has worked
> |
> | very well for this purpose). But now that it's being adopted I think
> | it's time to take it to the next level and fix the divergence if we
> | can.
> |
> | So can I ask you to provide us with the current 'correct' current
> | superclass implementation that we should use for the next set of
> | experiments?
> |
> | Cheers,
> |    - Andreas
> |
> | On 5/15/2010 10:53 AM, Dale Henrichs wrote:
> |>  Andreas,
> |>
> |>  It _is_ the curse of not having a common superclass...but until
> | Metacello is included in the base release, the curse would be getting
> | the common superclass loaded BEFORE you can load any configurations.
> |>
> |>  In the early versions of Metacello the configs were subclassed off
> | of a common superclass, but bootstrapping was a complete pain, since
> | you couldn't use Metacello to load itself.
> |>
> |>  As it stands now, you can load any configuration into any image. If
> | you create your configurations by copying MetacelloConfigTemplate
> | (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration)
> | then you will get a config that has all of the "expected" methods,
> | including #load on the class-side.
> |>
> |>  To be clear...the only only reason that I don't use the common
> | superclass model, is to make bootstrapping easy....If a
> | MetacelloAbstractConfiguration class were included in the core image
> | for Squeak, Pharo, and GemStone then we could migrate away from the
> | current "self-contained" configurations.
> |>
> |>  The class would be a clone of MetacelloConfigTemplate and existing
> | configs could easily be converted to use the new superclass....
> |>
> |>  The ensureMetacello logic would be included in the abstract
> | superclass so it wouldn't be necessary to include the core
> | implementation of Metacello in the base...
> |>
> |>  I'm sure the Pharo folks would be in favor of this (as would I,
> | speaking for GemStone)...
> |>
> |>  Dale
> |>  ----- "Andreas Raab"<andreas.raab at gmx.de>   wrote:
> |>
> |>  | On 5/14/2010 6:38 PM, Chris Cunnington wrote:
> |>  |>   ConfigurationOfExternalWebBrowser perform: #loadLatestVersion
> |>  |>
> |>  |>   Why?
> |>  |>   There is no #loadLatestVersion on the class side either.
> |>  |>
> |>  |>   There is #lastMetacelloVersionLoad. I try:
> |>  |>
> |>  |>   ConfigurationOfExternalWebBrowser perform: #loadLatestVersion
> |>  |>
> |>  |>   Nope, that's a dud.
> |>  |>
> |>  |>   My summary is this: if you install a config and it has #load on
> | the
> |>  |>   class side, you're golden. If not, then you're in a world of
> | the
> |>  | unknown.
> |>  |>   All things being equal, I'd say that Dale has created this with
> |>  |>   something in mind where this is not a problem. Maybe it's a
> | Pharo
> |>  | thing.
> |>  |>   Perhaps they have a tool that fills in the gap. But for me: no
> |>  | #load,
> |>  |>   means no go. And until we can get a standard API here, then
> | it's
> |>  | flawed.
> |>  |>   I'm guessing that you used AppleScript on some configurations
> | that
> |>  | had
> |>  |>   #load, and now you've found one that doesn't.
> |>  |
> |>  | It's the curse of not having a common superclass. Various variants
> | get
> |>  |
> |>  | created because there's no shared standard. I think the canonical
> | form
> |>  |
> |>  | is actually this:
> |>  |
> |>  | 	ConfigurationOfXXX project load.
> |>  |
> |>  | But I could be wrong; I'm no Metacello expert.
> |>  |
> |>  | Cheers,
> |>  |    - Andreas
> |>
> |>
>