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

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Tue Apr 21 10:00:31 PDT 2015


On Tue, Apr 21, 2015 at 1:50 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>  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?).
>
>

Thanks Dale, that is pretty clear.



> 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> 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
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150421/4b60bc3a/attachment-0001.html>


More information about the Glass mailing list