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

Sebastian Heidbrink via Glass glass at lists.gemtalksystems.com
Sat Apr 18 18:51:57 PDT 2015


Hi Dale,

which are the branches on has to load in order to get this package in a 
tODE image?

I am missing he TDShell forSessionNamed: method.

Am I right that this would be the implementation?
TDShell class >>
forSessionNamed: aSessionName
   ^ self sessionDescription: (TDSessionDescription importFrom: self 
sessionDescriptionHome, aSessionName)

Cheers
Sebastian


On 2015-04-15 10:23 PM, Dale Henrichs via Glass wrote:
> 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/
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

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


More information about the Glass mailing list