[Glass] GsDevKit Server Blocks for Thin Client appications ... pre-announcement
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Thu Apr 23 10:58:09 PDT 2015
On Wed, Apr 22, 2015 at 1:53 AM, Richard Sargent <
richard.sargent at gemtalksystems.com> wrote:
> Mariano,
>
> Depending on what you mean by "execute stuff on server Y", 3.2 includes
> something called GsExternalSession. It it capable of executing Smalltalk
> specified in Block on a separate session against the same stone or a
> different one.
>
> It doesn't support copying object graphs, but if your definition of
> execute stuff has limited requirements for exchanging data, it could be
> what you are looking for.
> See the 3.2 documentation for details.
>
Good to know too. Thanks Richard.
> On Apr 21, 2015 7:01 PM, "Mariano Martinez Peck via Glass" <
> glass at lists.gemtalksystems.com> wrote:
>
>>
>>
>> On Thu, Apr 16, 2015 at 2:23 AM, Dale Henrichs via Glass <
>> glass at lists.gemtalksystems.com> 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 ].
>>>
>>
>>
>> Dale,
>>
>> I know (because I already asked a few months/years ago) that from a stone
>> X you can do a remote login on stone Y and execute stuff in Y. But now I
>> wonder....could server blocks also work for gemstone-gemstone? (my gut
>> feelings tell me that yes) I mean, could I run the above code from GemStone
>> itself? That would automatically resolve all the remote login stuff and
>> the ston serialization.
>>
>> Thanks in advance,
>>
>>
>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150423/6a427f95/attachment-0001.html>
More information about the Glass
mailing list