[Glass] GsDevKit Server Blocks for Thin Client appications ... pre-announcement
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Tue Apr 21 08:57:30 PDT 2015
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. 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.
I hope I have the chance in the future to try this out.
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.
On Sun, Apr 19, 2015 at 12:54 AM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:
> Sebastian,
>
> Follow these directions to do use the server blocks install[1] ... for
> best results right now follow all of the steps with a fresh clone so you'll
> get the right checkout of gsDevKitHome and tODE ... the standard installs
> are written to work with the master branches, but both projects are in
> development ... part of the installation instructions arrange for you to
> load the dev branch of tode in both pharo and gemstone...
>
> Dale
>
> [1]
> https://github.com/GsDevKit/gsDevKitHome/blob/dev/projects/roassal/devBootstrap.md#roassal-visualization-setup-and-install
>
>
> On 4/18/15 6:51 PM, Sebastian Heidbrink via Glass wrote:
>
> 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 listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
> _______________________________________________
> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
> _______________________________________________
> 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/20150421/52b20ddb/attachment-0001.html>
More information about the Glass
mailing list