Distributed Objects

[TriSebastian]

Hi All!
I just wanted to have a close rlook at the VAST Distributed Objects package.
There are three questions I have.

1. In the online help documentation there's a tool menu mentioned which sould be shown in SystemTranscript after loading the Distributed Objects map. but I can'T find it. Any hints?
2. Is there somebody around how uses these? Can you guy provide me with some links to documentations, or articles?
3. Starting several images on one machine. Do I have to take care that they are started on different cores? I f yes how? Or is it managed by the OS?

Thank you very much!
Sebastian

[wembley]

Sebastian -

1) Did you load the Distributed Objects map using the Feature Loader (good) or did you just load the map (bad)?

2) We'll look around a bit for something to send you.

3) Multiple images can all run on a single core.

[TriSebastian]

Hi John!

Thank you very much for the fast reply!

Well, I loaded it with features. The only menu I can find is under Tools -> SST -> Use Distributed Debugger
I must be blind

Well, I implemented a graph placing algorithm with Seaside FrontEnd a few years ago. I used Squeak at that time and I wanted to port it to VAST now.
Calculation can take quite while and I thought it might be an ideal playground with "Distributed Objects" just to do these calculations on an additional image. This way clients to other seaside apps won't really get botherd by ongoing calculations in other sessions this much,... well at least,... a playground idea.
But getting full advantage of this might need the additional image to run on the other cpu, doesn't it?

In addition to that, as you know, I'm gambling arounf with OpenGL and NVIDIA Physx on VAST. Here we have three tasks that might be able to be split to several images. Userinteraction, OpenGL-rendering, Physx handling.... but this is really a playground idea, because I assume that using the tcp protocol might lead to way to much latency. But if the concept might get proven there might be an additional step to replace the tcp connection by a direct one, or primitive one...

hmmm.... 10 hours a workday are simply not VASt enough .
There was also the package "Interfaces",.. but this seems like beeing even less documented and it has, at least I think I can remember, Trailblaizer as a prerequisite...

Hach,... so many ideas and so few time.

Sebastian

[wembley]

Sebastian -

OK, you loaded using Feature Load. But you didn't say what menu (or menus) you think should be there that isn't. Yes, I could stop what I'm doing and go search through the doc, but I'd rather you just tell me

[TriSebastian]

Hi again!

Sorry, I simply forgot to mentin that. I't really hard to find. I can't find the site I got this from, but it is mentioned here, too.
Distributed feature adds menu to Transcript...
http://www.instantiations.com/docs/802/ ... rat72.html
Well, I hope this is not just XD related...

Sebastian -

[wembley]

Sebastian -

Your link points to the Migration Guide (in particular, the section on migrating from the old Distributed feature to the new SST set of features). I think you should be reading the Server Smalltalk Guide instead. But if you continue to read in the Migration Guide, the things you should expect to see are listed under the SST equivalent heading on each of these pages.

[TriSebastian]

Thank you,

I got it:
http://www.instantiations.com/docs/802/ ... sst48.html
There's are just those entries mentiond like I currently have in my IDE.

Pchuii..., though I expect the samples to be based on the SST Documentation, I won't have to be scared not to be able to follow the samples.
First work really fine. I wonder why I didn't hear anything about this massiv implementation before.
Looks very interesting.

Thank you for the clarification.
Sebastian

[marten]

A nice book about the distributed objects feature (the framework before SST) is "VisualAge for Smalltalk Distributed - Developing Distributed Object Applications".

Though this book covers the older framework, it is still a good book about problems, design decisions, general discussions when entering the field of distributed programming using Smalltalk.

It's of course out of print - but was published by Prentice Hall/IBM 0-13-570805-2.

Marten

[TriSebastian]

Thanks Marten,

I already ordered it this week...

The more I read in the instantiations online help the more I get into the topic. I also found out, that the package "Interfaces" is also part of the documentation,... but it is called "Object Space"...

Well, I hope I'll find enough time to follow my ideas.

I'm really wondering that there's no other resource on the web. I'm also wondering why there's nothing like those Backgroundworkers available in VAST (well they are, but not in relation to GUI),.... just like those in .Net. It's sad but true,... many things that are promoted as new edge technology in .Net have already been available in Smalltalk years before other environments came up with it.
I know so many applications which don't really take advantage of several GUI threads just because of fear of synchonisation,... but having a look at Distributed Objects,... this fear is not really traceable for me.

I'll go on having a closer look.

Sebastian

[koschate]

Working with remote objects can be as simple and transparent as working with local objects, but you do have to adhere religiously to the Law of Demeter. Using local methods to traverse a remote object tree can absolutely destroy performance.

Packaging also presents interesting challenges. As is usually good advice, start packaging as early as possible. You will almost certainly need to make use of SstUrl class>>#addPackagingRulesFor:to: and SstTransport class>>#addPackagingRulesFor:to: in order for the packaged images to work correctly. You might also need to provide a '-platform WIN32s" or "-platform MOTIF" as part of the runtime image invocation.

Debugging packaging issues tends to be problematic because often the image will die without leaving any sort of trace behind. In those cases, you find it necessary to insert EsWindowSystemStartUp class>>#outputWalkback: in strategic locations to figure out exactly where things are dying.