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

[Dale Henrichs via Glass]

A GsDevKit Server Block[1] is a block that is written in-line in client 
Smalltalk, but is executed in GemStone. For example the following 
expression is executed in a standard Pharo workspace:

   | shell x y |
   shell := TDShell forSessionNamed: 'devKit'.
   x := 3.
   y := 4.
   shell onServerDo: [ x + y ].

and the `[3 + 4 ]` block is executed in GemStone using the `devKit` 
session description to log into the stone. The temp vars x and y 
referenced in the server block and defined in Pharo are shipped across 
the wire to GemStone along with block source where the block source is 
compiled and executed. The result is then shipped back across the wire 
and returned as the result of #onServerDo: message in Pharo. Pharo 
execution can continue on using the result. STON[2] is used to serialize 
the objects that are shipped across the wire.

For any of you familiar with underpinnings of GemTools, Jade or tODE, 
this is not necessarily ground-breaking technology, however, exposing 
this capability to developers just may be.

It has been a long standing crime that developers in the Pharo community 
choose to use  MongoDB and MySQL over GemStone, but frankly the problem 
is that (until now) we have not had a simple client-based solution for 
adding GemStone-based persistence for native Pharo applications - the 
pharo developers have not really had a choice.

Being able to embed server blocks in client code certainly qualifies as 
simple. Solution(?), well that remains to be seen, but I am optimistic.

As a more concrete example, here's Pharo workspace code that uses NeoCSV 
running in Pharo to load stone objects in a Dictionary in GemStone:

   'NeoCSVBenchmark.csv' asFileReference
   readStreamDo: [ :stream |
   | reader converter buffer bufCnt numRecords records |
   converter := [ :string | NeoNumberParser parse: string ].
   reader := NeoCSVReader on: (ZnBufferedReadStream on: stream).
   reader
     recordClass: NeoCSVTestObject;
     addIntegerField: #'x:';
     addIntegerField: #'y:';
     addIntegerField: #'z:'.
   buffer := Array new: 1000.
   bufCnt := 0.
   [ reader atEnd ]
     whileFalse: [
       bufCnt := bufCnt + 1.
       buffer at: bufCnt put: reader next.
       bufCnt = buffer size
         ifTrue: [
           numRecords := bufCnt.
           records := buffer.
           DevKitShell
             onServerDo: [
               1 to: numRecords do: [ :index |
                 | record |
                 record := records at: index.
                 NeoCSVDictionary at: record x put: record ].
               System commitTransaction.
               nil ].
           bufCnt := 0 ] ] ].
    DevKitShell onServerDo: [ System commitTransaction ]

The code ships 1000 instances of NeoCSVTestObject at a pop to GemStone. 
Using the above technique, one can easily arrange to store some pretty 
large object graphs in GemStone ... Efficient queries based on standard 
Smalltalk can be written on the client and transparently performed in 
GemStone (see the GsDevKitServerBlocks doc[1] for the complete example).

Server blocks do not duplicate the functionality GemBuilder for 
Smalltalk[6][7] which provides transparent replication and maintenance 
of objects between the client and server. With server blocks you end up 
with disconnected copies of server objects.

Because of this disconnect, I think the best way to architect an 
application using server blocks, is to plan on "executing all business 
logic" on the server --- If you are using an MVC pattern, the M would 
primarily be managed on the server while the VC would be managed on the 
client.

As an application evolves, the code can migrate back and forth between 
client and server as needed.

Most of the server blocks code leverages tODE and has been in use for 
several years. The code that spelunks in the block structure and 
extracts the _value_ of temp variables is only a couple of days old and 
has some pretty rough edges (notice the odd placement of temp variables 
and declarations in the above example).

The server-side debugger and inspectors, etc. will use tODE (at least 
for now) ...  in the server blocks doc[1] I demonstrate an 
#exportClassToServer: to illustrate the potential to share code in weird 
and wonderful ways between the client and server.

If you have the interest/opportunity to take this code for a spin, let 
me know. I have written instructions[5] for installing the experimental 
Roassal Visualization code[4] (GemStone and Pharo3.0 or Pharo4.0) for 
Pierre Chanson and those instructions can be used for doing work with 
GsDevKit
Server Blocks. There are a handful of obvious things that need to be done:
   - connection pools
   - coordinated client/server debuggers
   - client-side exception handlers for server errors
   - more???
and if folks express interest in start to do exploratory work with 
server blocks, then I will make time to provide support.

I am hoping to have something to announce by Smalltalks in November,so 
it would be useful if some experienced GemStoners tried things out 
before then...

I do have to finish up the documentation for GsDevKitHome 1.0.0 and tODE 
0.1.0 and I'm also committed to doing some work on the 3.3 GemStone 
release, so we'll see how that goes:)

I also think that server blocks can be very useful for the "develop in 
Pharo, deploy in GemSstone" crowd, since it will be possible to write 
"pharo-based scripts" to perform server-side tasks ...

Questions or comments?

Dale

[1] 
https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/articles/gsDevKitServerBlocks.md#gsdevkit-server-blocks
[2] https://github.com/GsDevKit/ston#ston---smalltalk-object-notation
[3] https://vimeo.com/123261640
[4] 
https://github.com/GsDevKit/gsDevKitHome/tree/dev/projects/roassal#roassal-visualization
[5] 
https://github.com/GsDevKit/gsDevKitHome/blob/dev/projects/roassal/devBootstrap.md
[6] http://gemtalksystems.com/products/gbs-vw/
[7] http://gemtalksystems.com/products/gbs-va/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150415/38f1a6d0/attachment-0001.html>