[Glass] GsDevKit Server Blocks for Thin Client appications ... pre-announcement

[Dale Henrichs via Glass]

There are a couple of things going on with STON serialization:

1. Out of the box STON works with pure  indexable classes and pure 
non-indexable classes. Classes with instance variables and indexable 
fields will cause STON to choke. BUT it is possible to write a custom 
serializer for those instances. See the Text class in a tODE stone for 
an example.

2. The class must be defined on both systems otherwise custom 
serialization code must be written ...

3. Out of the box STON expects to find the same set of instance 
variables on both sides. STON represents objects as  a collection of 
instance variable name/value pairs (or an indexed list of values) and 
when de-serializing will throw an error if an instance variable is 
missing ... Again custom serializer code can be written to paper over 
minor differences between implementations.

With that said, it is pretty easy to write custom serialization ...

So out of the box you can depend upon the list of classes in 
STONWriterTests to work, plus any pure non-indexable/indexable classes 
that have the  same shapes on both systems will work.

For example if your model code is loaded on both Gemstone and Pharo and 
the object graph is made up ov common classes, the you can pass 
instances of your model across the wire with the caveat that identity is 
not maintained (can you say custome serialization?).

Dale

On 04/21/2015 09:32 AM, Mariano Martinez Peck wrote:
>
>
> On Tue, Apr 21, 2015 at 1:24 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>
>     On 04/21/2015 08:57 AM, Mariano Martinez Peck wrote:
>
>         Hi Dale,
>
>         This is very interesting!!! Not exactly right now, BUT at some
>         point in the future, i was thinking an scenario where this
>         could really be of help. Basically, I have some jobs that
>         would take hours/days to run (for example neural networks
>         implementations for backtesting and automated trading). And
>         these jobs may not read/write much of the data in GemStone. So
>         what I thought is to fire up several Pharo images to split the
>         work and to avoid collapsing the stone that will be used for
>         other things as well.
>
>     Yes this type of "light weight" stone access is one of the things
>     that server blocks are good for ... you can login and logout on
>     demand so there is no need to keep sessions alive for long periods
>     of time ...
>
>         With that strategy in mind, I needed to somehow resolve the
>         read/write of the little data I need (either REST + json or
>         whatever). But this server blocks idea may be exactly what I need.
>
>     Yep ... I think the best model is to keep things simple (thus the
>     emphasis on thin client) ... but the built-in STON access and the
>     ability to execute arbitrary Smalltalk on the server makes server
>     blocks superior to a restful interface ... Obviously for external
>     use REST is the right thing but for trusted clients it's really a
>     good way to go ...
>
>
>
> Dale,
>
> I fully agree with all you said. There is something I would really 
> like to know and it's about the exact type of primitive objects that 
> can successfully be serialized from Pharo to GemStone (are these the 
> tests of STONWriterTests?) . That is... the tempvars 'x' and 'y' of 
> your example. I think I remember you saying there were some problems 
> with certain type of objects....
>
>         I hope I have the chance in the future to try this out.
>
>     Drop me a line before trying in case the api or dev instructions
>     change[1].
>
>     [1]
>     https://github.com/GsDevKit/gsDevKitHome/blob/dev/projects/roassal/devBootstrap.md#roassal-visualization-setup-and-install
>
>
>         Thanks a lot, very interesting.  I have some other ideas in
>         mind...like consuming a no-sql or sql db from pharo and push
>         data into gemstone (otherwise you would need to find another
>         way). Anyway...lots of ideas come to my mind where this could
>         be useful.
>
>     That's what is nice about server Blocks ... they provide a
>     low-level and simple interface to GemStone upon which interesting
>     capabilities can be built ...
>
>     Dale
>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150421/d0aea5a2/attachment.html>