[Glass] GsDevKit Server Blocks for Thin Client appications ... pre-announcement
Sebastian Heidbrink via Glass
glass at lists.gemtalksystems.com
Wed Apr 15 23:02:51 PDT 2015
Hi Dale,
that is amazing news! Thank you!
There is one thing that I would love to try out!
Could you please compile the needed communication dlls for RaspbianOS on
ARM architecture.
I would love to try out to connect ScratchOnPi with the needed tODE
layer and serverBlocks during the Spring CampSmalltalk in Nanaimo,BC
Canada end of April.
The only thing I am not really aware of is the question if it is
possible at all to load the tODE communication layers into a Squeak
image? Would it?
It is really too unfortunate that Pharo's VirtualGPU needs NativeBoost
which is not available for the ARM VMs.... The other thing I would love
to try out is having a Gemstone Pharo VirtualGPU tODE-ServerBlock
Parallella board setup.
So if somebody has an idea on how to set this up, please let me know or
come to the CampSmalltalk ;-)
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/20150415/14ddda07/attachment.html>
More information about the Glass
mailing list