tODE, kaliningrad, cypress, ….

Dale,

it seems your shooting tools like crazy into the wild. Is there some big picture drawn anywhere that explains what your mad and genius mind has planned for us and the rest of the universe? And I'm interested which tools are developed and which of them are soooo last week so I don't need to look at.

The specific question is what is the state of the art for communicating with gemstone. I think I can take a lot of pain and used stubbornly the gemtools for my deployments. Now I developed my first gemstone in EC2 and it is just unusable for me. My hosting provider outperforms amazon by a factor of 10 if it comes to latency. I had not much time to follow development of yours. There was some tODE + amber + ... which sounds wonderful but I couldn't find further information. So I must assume it was only in my dreams.

Norbert

Norbert,

There is a mad plan of sorts.  

If you think about tODE, you need to coordinate Amber source with GemStone/Pharo source as the three code bases are coupled together ... Kaliningrad was my first shot at storing Amber in Monticello (via Seaside), but it isn't easy to keep Kaliningrad in synch with Amber, since you have to keep copying Amber .js files into Seaside FileLibrary methods ... not pretty and very difficult to keep in synch ... I wasn't looking forward to incorporating the Amber 0.9.1 into Kaliningrad.

Another aspect with the 3 dialect coordination is that there is a fair amount of common code that needs to get pushed around and the overhead for keeping all of the configurations in synch is too high especially without better tools support for Metacello. I have some passable Metacello tools in tODE but better support is needed especially for merging at the configuration level...

Then along came the git/github. With git/github the crying need for better Metacello tools will be practically eliminated ... Metacello is only needed for package and project dependency specifications ... git handles the version management very nicely and the merge support for multi-package and cross dialect merging is very nice in git ...

By diverting effort to git/github now, things will be smoother down the road ... and my support load for Metacello will be significantly reduced ...

The disk-base package format is nailed, but I still need to figure out how to integrate Metacello and disk-based source, so I've been putting cycles in to the Cypress stuff to get a feel for how to manage cross-dialect smalltalk ... it looks like platform-specific branching is the way to go ...

but I'm still trying to figure out how to do the project dependency stuff ... git submodules work very nicely, but I'm afraid that they will start to break down if the nesting of projects gets too deep..

Add to this the fact that working with Smalltalk source in directory structures is something "new" ...

So I'm still casting about a bit ... I've had several crazy ideas, but I am looking for something simple and I'm holding out a bit for that inspiration.

The Amber Skeleton project turns out to be very interesting ... I've got Pharo and Amber source code all managed under one Git project ... I'm thinking that adding a server/gemstone directory to the project structure and not only can we work with Amber/Pharo/GemStone in the same project structure, but I think that this approach will have an impact on the develop in Pharo deploy in GemStone work ...

Which of course plays right into tODE ... where this all started:)

The current order of business is to get finish the Seaside upgrade work for 3.1 (the Cypress work has been fit into the cracks of the upgrade work while I wait for long running processes to complete:)

Once I've got the migrations put to bed, I've got to make some decisions on the Metacello support for disk-based repositories ... Metacello will be the transition glue that will allow for an orderly migration from mcz repositories to github repositories... once the decisions are made the code will follow pretty quickly ... the learning part just takes time tho...

Then I should be able to get back to work on tODE and GLASS ...

You should consider loading up tODE[1] in a local stone and playing with the tools a bit to see if you can perform the types of tasks you need to perform on the remote stones from tODE as it stands today ... for certain tasks it is definitely superior to GemTools ...

Dale

[1] http://code.google.com/p/tode/

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Tuesday, April 24, 2012 12:35:46 AM
| Subject: [GS/SS Beta] tODE, kaliningrad, cypress, ….
|
| Dale,
|
| it seems your shooting tools like crazy into the wild. Is there some
| big picture drawn anywhere that explains what your mad and genius
| mind has planned for us and the rest of the universe? And I'm
| interested which tools are developed and which of them are soooo
| last week so I don't need to look at.
|
| The specific question is what is the state of the art for
| communicating with gemstone. I think I can take a lot of pain and
| used stubbornly the gemtools for my deployments. Now I developed my
| first gemstone in EC2 and it is just unusable for me. My hosting
| provider outperforms amazon by a factor of 10 if it comes to
| latency. I had not much time to follow development of yours. There
| was some tODE + amber + ... which sounds wonderful but I couldn't
| find further information. So I must assume it was only in my dreams.
|
| Norbert

Dale,

thanks for the detailled explanation. I'm not sure I understand everything but then I didn't even make it to follow the metacello list since a while. It is good to know tODE hasn't been abandoned. So I'll give it a try.

Norbert

Am 24.04.2012 um 11:16 schrieb Dale Henrichs:

Hi Dale,

One idea I have in mind recently and after little brainstorming it seems
not so hard to implement:

1. Amber for remote tools including browser, debugger, inspector, ...
3. REST API on server images (being plain Smalltalk ones or Gemstone)

REST approach for remote communication is preferable because tools
become much loosely coupled. Also you can use tools other than Amber
(like some direct source code control to an image). Disadvantage is that
REST protocol shall be defined upfront and implemented in REST API. This
API could be implemented on top of current Zinc tools only. With
security/authentication/authorization included.

It seems all cloud technology goes this path, so we are again not far
from the others with such an approach.

Best regards
Janko


Dne 24. 04. 2012 11:16, piše Dale Henrichs:
--
Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565

Janko,

That's the basic idea behind tODE with a few twists ... One of the things that I'n doing with tODE is trying not to just duplicate all of the classic tools directly in Amber ... It's an approach that could be taken, but for me I am pursuing the idea that tODE should put developers closer to the objects that they are working with ... The class smalltalk tools get between the developer and the objects and I think there are ways to break down some of those barriers ... so that's what tODE will become ...

I would like to invite collaboration on the work for tODE, but the number of moving parts: Amber, javascript libraries, pharo, squeak, gemstone server-side code is calling out for git/github ... with git and github I think that the collaboration tasks become manageable...

Dale

----- Original Message -----
| From: "Janko Mivšek" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Tuesday, April 24, 2012 4:31:40 AM
| Subject: Re: [GS/SS Beta] tODE, kaliningrad, cypress, ….
|
| Hi Dale,
|
| One idea I have in mind recently and after little brainstorming it
| seems
| not so hard to implement:
|
| 1. Amber for remote tools including browser, debugger, inspector, ...
| 3. REST API on server images (being plain Smalltalk ones or Gemstone)
|
| REST approach for remote communication is preferable because tools
| become much loosely coupled. Also you can use tools other than Amber
| (like some direct source code control to an image). Disadvantage is
| that
| REST protocol shall be defined upfront and implemented in REST API.
| This
| API could be implemented on top of current Zinc tools only. With
| security/authentication/authorization included.
|
| It seems all cloud technology goes this path, so we are again not far
| from the others with such an approach.
|
| Best regards
| Janko
|
|
| Dne 24. 04. 2012 11:16, piše Dale Henrichs:
| > Norbert,
| >
| > There is a mad plan of sorts.
| >
| > If you think about tODE, you need to coordinate Amber source with
| > GemStone/Pharo source as the three code bases are coupled together
| > ... Kaliningrad was my first shot at storing Amber in Monticello
| > (via Seaside), but it isn't easy to keep Kaliningrad in synch with
| > Amber, since you have to keep copying Amber .js files into Seaside
| > FileLibrary methods ... not pretty and very difficult to keep in
| > synch ... I wasn't looking forward to incorporating the Amber
| > 0.9.1 into Kaliningrad.
| >
| > Another aspect with the 3 dialect coordination is that there is a
| > fair amount of common code that needs to get pushed around and the
| > overhead for keeping all of the configurations in synch is too
| > high especially without better tools support for Metacello. I have
| > some passable Metacello tools in tODE but better support is needed
| > especially for merging at the configuration level...
| >
| > Then along came the git/github. With git/github the crying need for
| > better Metacello tools will be practically eliminated ...
| > Metacello is only needed for package and project dependency
| > specifications ... git handles the version management very nicely
| > and the merge support for multi-package and cross dialect merging
| > is very nice in git ...
| >
| > By diverting effort to git/github now, things will be smoother down
| > the road ... and my support load for Metacello will be
| > significantly reduced ...
| >
| > The disk-base package format is nailed, but I still need to figure
| > out how to integrate Metacello and disk-based source, so I've been
| > putting cycles in to the Cypress stuff to get a feel for how to
| > manage cross-dialect smalltalk ... it looks like platform-specific
| > branching is the way to go ...
| >
| > but I'm still trying to figure out how to do the project dependency
| > stuff ... git submodules work very nicely, but I'm afraid that
| > they will start to break down if the nesting of projects gets too
| > deep..
| >
| > Add to this the fact that working with Smalltalk source in
| > directory structures is something "new" ...
| >
| > So I'm still casting about a bit ... I've had several crazy ideas,
| > but I am looking for something simple and I'm holding out a bit
| > for that inspiration.
| >
| > The Amber Skeleton project turns out to be very interesting ...
| > I've got Pharo and Amber source code all managed under one Git
| > project ... I'm thinking that adding a server/gemstone directory
| > to the project structure and not only can we work with
| > Amber/Pharo/GemStone in the same project structure, but I think
| > that this approach will have an impact on the develop in Pharo
| > deploy in GemStone work ...
| >
| > Which of course plays right into tODE ... where this all started:)
| >
| > The current order of business is to get finish the Seaside upgrade
| > work for 3.1 (the Cypress work has been fit into the cracks of the
| > upgrade work while I wait for long running processes to complete:)
| >
| > Once I've got the migrations put to bed, I've got to make some
| > decisions on the Metacello support for disk-based repositories ...
| > Metacello will be the transition glue that will allow for an
| > orderly migration from mcz repositories to github repositories...
| > once the decisions are made the code will follow pretty quickly
| > ... the learning part just takes time tho...
| >
| > Then I should be able to get back to work on tODE and GLASS ...
| >
| > You should consider loading up tODE[1] in a local stone and playing
| > with the tools a bit to see if you can perform the types of tasks
| > you need to perform on the remote stones from tODE as it stands
| > today ... for certain tasks it is definitely superior to GemTools
| > ...
| >
| > Dale
| >
| > [1] http://code.google.com/p/tode/
| >
| > ----- Original Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Tuesday, April 24, 2012 12:35:46 AM
| > | Subject: [GS/SS Beta] tODE, kaliningrad, cypress, ….
| > |
| > | Dale,
| > |
| > | it seems your shooting tools like crazy into the wild. Is there
| > | some
| > | big picture drawn anywhere that explains what your mad and genius
| > | mind has planned for us and the rest of the universe? And I'm
| > | interested which tools are developed and which of them are soooo
| > | last week so I don't need to look at.
| > |
| > | The specific question is what is the state of the art for
| > | communicating with gemstone. I think I can take a lot of pain and
| > | used stubbornly the gemtools for my deployments. Now I developed
| > | my
| > | first gemstone in EC2 and it is just unusable for me. My hosting
| > | provider outperforms amazon by a factor of 10 if it comes to
| > | latency. I had not much time to follow development of yours.
| > | There
| > | was some tODE + amber + ... which sounds wonderful but I couldn't
| > | find further information. So I must assume it was only in my
| > | dreams.
| > |
| > | Norbert
| >
|
| --
| Janko Mivšek
| Svetovalec za informatiko
| Eranova d.o.o.
| Ljubljana, Slovenija
| www.eranova.si
| tel:  01 514 22 55
| faks: 01 514 22 56
| gsm: 031 674 565
|