2016-09-05 15:40 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

And here is working script to load it:

Metacello new smalltalkhubUser: 'Pharo' project: ’Seamless'; configuration: ’Seamless'; version: #stable; load

Loading by Gofer or directly by configuration is not working now (it is really strange)

And it fixed (Gofer and ConfigurationOfSeamless work)

2016-09-05 15:52 GMT+02:00 philippe.back@highoctane.be < philippe.back@gmail.com>:

What is TostSerializer ?

It is new binary serialization library which supposed to be used for objects transport. It not provides any meta data or support for object migration like Fuel. So it should not be used as persistence option. It processes given objects as stream of references by directly writing them on destination stream. Actually it implements old Squeak ReferenceStream but in different way which is suitable for Seamless usage (Seamless extends it). Comparing to Fuel - much faster for small objects (~50 times for serialization and ~3 times for materialization) - much faster for substitutions (which is usual case for Seamless) - but Fuel is champion for big objects materialization (10 times better) - much compact for small objects and relatively similar for big (strangely compressed Tost binary is twice lesser) - serialization object representing integer result takes 21 byte for Tost and 400 for Fuel

Hi Sean. 2016-09-05 16:39 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:

Awesome! Is this "the" Pharo library for sharing live objects between images? IIUC it's a successor to rST, correct?

Yes, it is new implementation of remote smalltalk. Look at my blog for details and docs http://dionisiydk.blogspot.fr/2016/07/major-seamless-update.html

Are there other remote communication libraries, and if so how does Seamless compare?

I guess you skipped my previous announcement. Just look at my blog. In short old rST was not flexible enough to solve particular problems. And Nikolaos Papoulias started Seamless to address these issues with better design ideas. I move it forward and now Seamless drives RemoteDebugger project where regular debugger works with remote stack. And in future we will got remote browser too.

2016-09-06 16:37 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:

Denis Kudriashov wrote

...

Yes, it is new implementation of remote smalltalk. Look at my blog for details and docs http://dionisiydk.blogspot.fr/2016/07/major-seamless-update.html

Wow! This is really awesome. I love that you don't have to have the classes loaded in the image to deal with the proxies. I've been running into a problem lately that I have many images with overlapping domains that need to talk to each other.

But it could be problem if you will manage your domain objects be transferred as value. Different format of objects in such cases will be problem.

It's gotten messy because by default I use SimplePersistence and it's easy to get into hairy situations where the data gets unsynced. Could Seamless be appropriate for general inter-image communication or is there a better alternative?

It is appropriate. But one important feature is absent now. It is distributed garbage collection. During network lifetime unused proxies and references are not collected. It can be performed only manually (for example when you close network and it collected by itself or there is "network destroy" command). Alternative of course is classic http services (Zinc) without any magic.

2016-09-06 18:01 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:

Is that to say that the network holds them strongly?

yes

2016-09-06 19:06 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:

Denis Kudriashov wrote

...

...

Is that to say that the network holds them strongly?

I'm curious, why?

Imaging we send object A from server to client as reference. On client object A will be represented by proxy and any message to it will produce remote interaction with object A on server side. Now what will happen if server will collect object A as garbage? Proxy on client will become broken because it will point to unexisting object on server and any message send will produce error. So simple weak arrays approach is not enough to manage distributed objects. Distributed garbage collection is required which is not implemented yet. Of course it is very important feature but for specific applications manual management is usable too. In case of remote debugging everything is cleaned when client disconnects debugger from server.