[Glass] General questions about how to develop ...

[James Foster]

On Nov 19, 2013, at 10:16 AM, itlists at schrievkrom.de wrote:

> If the application is running under a different user, he should not see
> the changes I made under user DataCurator !?

As Otto has described, that depends on where you put the data. Each user gets his or her own UserGlobals, but by default each user shares the same Published. Published is the designated place to put application classes and data that you want to share (by default, you can, of course, add other dictionaries to anyone’s SymbolList). 

Although, I wouldn’t use separate users. It just introduces (usually) needless complexity.

> Some other questions:
> 
> All users can the see the contents available under "Globals” ?

Yes, unless someone removed Globals from the user’s SymbolDictionary (which would be very strange).
> 
> A user "A" see its own/same contents of UserGlobals - even in different
> concurrent sessions  ?

As long as the first session commits and the second session does an abort or commit, then they see the same data.

> a e.g. user "B" can not see the content of UserGlobals of user "A” ?

Generally not, unless you reference user A’s UserGlobals from user B’s SymbolList (which would be very confusing).

> Its uncommon to use Smalltalk processes - as they are used in other
> Smalltalk environments - instead one should user worker gems to do heavy
> background job !?

If you are willing to have GemStone behave like other Smalltalks, then you can do everything in one Gem. The value of separate Gems is that it takes advantage of the GemStone feature of transaction isolation.

> If you have heavy calculation stuff one should consider exporting the
> computational data for background work in a non-Gemstone programming
> environment - to get most of the 2-cpu-limitation !?
> 
> Persistence is done by reachability - therefore the programmer must
> create a global persistent object, from which all other (persistent)
> application objects can be reached.This can be achieved via global
> entries in the UserGlobals directory or Globals - or perhaps much better
> in a class (instance) variables ?

This is a bit more of a judgment call. At one time class (instance) variables were not copied from one class version to another. So, if you added an instance variable to your class then all your persistent data disappeared. (Of course, it was still there, but not in the current version of the class so it looked like it was gone and it was a little complicated to get it back.) We have fixed that problem, so class (instance) variables are no longer quite such a bad idea. 

My current approach is to have an application manager class where an instance holds the key application objects (primarily collections). On the class side are methods that answer the default and current application and allow you to set the current application. The default application would be the production one while the current application (which defaults to the default) is stored in a SessionTemp. This allows you to use a temporary application object for testing, and you can even run tests in production (though I wouldn’t recommend it!). 

The default application object can be in a class (instance) variable or in a global. Because of the earlier problems with variables being lost when a new version was created, I got in the habit of using a global, and I still lean that way but can’t think of a compelling reason right now.

> Some more questions to come :-))) Thanks for answering …

It is fun to hear what you are doing. Keep it up!

> Marten Feldtmann

James