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

[Dale Henrichs via Glass]

On 04/30/2015 09:09 AM, Sebastian Heidbrink via Glass wrote:
> Hi Pierre,
>
> I dabbled around with the serverBlocks during CampSmalltalk, too and I 
> like your ObjectPointer solution.
Yes oops are very convenient for use on the client-side ... the caveat 
is that you have to be very aware of what you are doing when playing 
with oops ... a reference to an oop is not strong, so GemStone will 
freely create new objects with the same oop unless you take precautions 
... there are several different approaches that can be used to protect 
yourself that all boil down to creating a session-based reference to the 
objects that you are referring to by oop on the client ... just keep in 
mind that the longer-lived your client-side reference is the more 
complicated the solution becomes:) For references that are attached to a 
roassal window you are pretty safe ... if you start keeping and sharing 
objects around that have references to server objects via oops, you are 
wandering into some complicated territory.

This is why I mention Thin Clients in concert with Server Blocks ... 
short-lived references to oops  with restricted scope can be managed ...
> I just wanted to ask whethere there is some kind of lazy 
> initialiyation in Roassal? I encountered some issues.
>
> I also want to report a bug in the implementation and will file it as 
> soo nas I am working on this again.
> For the executeOnServer code string creation there is printString 
> used,.... this results in issues once you would like to upload longer 
> csv strings because they are trimmed and end with "...".
Did you look at my CSV example[1] (look at item 5) ... in that example 
the domain objects are created in Pharo shipped over the wire .... 
perhaps you are using a different technique? I didn't think that STON 
used printString for passing Strings, but then I could be wrong  or are 
you talking about real big workspaces?

Include a concrete example in your bug report  ....

[1] 
https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/articles/gsDevKitServerBlocks.md
>
> I also have trouble using this functionality from outside the workspace.
> E.g. this is more or less the same implementatin as the one in the 
> example and still the onserverDo: Block return an exception 
> complaining about a Parameter 1.
>
>
> 'mycsvFile.csv' asFileReference readStreamDo: [ :stream |  | records 
> numRecords line buffer bufCnt|
>         stream nextLine.
>          buffer := Array new: 10000.
>   bufCnt := 0.
>     line:= stream nextLine.
>   [ line notNil ]
>     whileFalse: [
>       bufCnt := bufCnt + 1.
>       buffer at: bufCnt put: line.
>       bufCnt = buffer size
>         ifTrue: [
>           numRecords := bufCnt.
>           records := buffer.
>           DevKitShell
>             onServerDo: [
>               1 to: numRecords do: [ :index |
>                 | record |
>                 record := records at: index.
>                 MyLineprocessor processLine: record.].
>               MySystemExtensionClass markForCollectionAndCommit .
>               nil ].
>           bufCnt := 0 ].
>     line:= stream nextLine].
>
>  ].
>
> Did you encounter these problems during your tests, too?
The temp variable extraction code is pretty shakey right now especially 
when it comes to nested blocks ... this is an area that deserves more 
attention ... to get the exported variable references and their values, 
I have to use the debugger data structure which works fine for the 
debugger and almost works for my use case (tantalizingly close), so I've 
had to make do with less complete techniques ... it's a solvable 
problem, but at the moment isn't really up to snuff ....

To work around this problem, try declaring temp vars inside block 
boundaries that get assigned the temp var value from the outer context 
... on second thought when you get back to this send me the actual 
workspace code and I'll see if I can jigger things to work:)

BTW, I see that in the above you are passing a buffer of lines across 
the wire ... is this the place where you are having trouble? I'm not 
sure I know where the printString gets involved other than in the STON code?
>
>
> I also want to add that there seems to be a limitation on connections 
> this interface can handle. During debugging I accidently didn't qiot 
> the shell properly and it doesn'T take long until the server had to be 
> restarted due to too many open connections errors.
Well this is very, very early code and you are responsible for managing 
your connections ... you are limited by the GemStone license in terms of 
the number of connections/gems that you can use ... eventually I will 
provide some sort of connection pool scheme ...

Dale

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150430/1951d7ea/attachment.html>