Hi,
I released new version of Seamless 0.9.0. It is based on specialized TostSerializer instead of Fuel. This version is ~4 times faster than previous one and produce much compact data packets. For example Fuel based version takes 400 bytes to return small integer as result of message send. Now it is just 21 bytes. Pharo 5 and 6 are supported. |
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) 2016-09-05 15:18 GMT+02:00 Denis Kudriashov <[hidden email]>:
|
In reply to this post by Denis Kudriashov
What is TostSerializer ? Le 5 sept. 2016 15:19, "Denis Kudriashov" <[hidden email]> a écrit :
|
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)
|
Administrator
|
In reply to this post by Denis Kudriashov
Awesome! Is this "the" Pharo library for sharing live objects between images? IIUC it's a successor to rST, correct? Are there other remote communication libraries, and if so how does Seamless compare? Thanks for all the great work you're doing!
Cheers,
Sean |
Hi Sean. 2016-09-05 16:39 GMT+02:00 Sean P. DeNigris <[hidden email]>:
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
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. |
In reply to this post by Denis Kudriashov
2016-09-05 15:40 GMT+02:00 Denis Kudriashov <[hidden email]>:
And it fixed (Gofer and ConfigurationOfSeamless work) |
Administrator
|
In reply to this post by Denis Kudriashov
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. 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?
Cheers,
Sean |
2016-09-06 16:37 GMT+02:00 Sean P. DeNigris <[hidden email]>:
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 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. |
Administrator
|
I don't understand. Does this relate to classes not being loaded in the system? Is that to say that the network holds them strongly?
Cheers,
Sean |
2016-09-06 18:01 GMT+02:00 Sean P. DeNigris <[hidden email]>: Is that to say that the network holds them strongly? yes |
In reply to this post by Sean P. DeNigris
2016-09-06 18:01 GMT+02:00 Sean P. DeNigris <[hidden email]>:
Imaging that you have Point with format (x,y) on server and with format (x,y,z) on client. In such case there will be problems while transferring Point instances as copy (by value) between server and client. But by default most of objects are transferred by reference. |
Administrator
|
In reply to this post by Denis Kudriashov
I'm curious, why?
Cheers,
Sean |
2016-09-06 19:06 GMT+02:00 Sean P. DeNigris <[hidden email]>:
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. |
Free forum by Nabble | Edit this page |