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

[Otto Behrens]

>>> -> Can I develop further on (in parallel) with Jade and DataCurator ?
>>
>> You can do that. But surely you may break the application while you
>> are working if your end user is on it at the same time?
>>
>
> If the application is running under a different user, he should not see
> the changes I made under user DataCurator !?
> Some other questions:
>
> All users can the see the contents available under "Globals" ?
>
> A user "A" see its own/same contents of UserGlobals - even in different
> concurrent sessions  ? a e.g. user "B" can not see the content of
> UserGlobals of user "A" ?

It depends on how it is set up in the database. Some things can have
shared visibility, others not. In short, if you are really familiar
with GemStone, you can try this out, but I think this is treacherous
ground.

Shortly, here's how it works:

- Every user has his own symbol list (System myUserProfile
symbolList). A symbol list is a list of dictionaries that contain the
visible symbols (i.e. any class name & global variable). Some of the
dictionaries (called SymbolDictionaries) are shared (eg. Globals) and
some may be kept private (UserGlobals).
- Classes in GemStone are instances of Metaclasses, the same way that
it is in other Smalltalks. But, because of this setup, you can have
multiple concurrent instances of classes with the same name. Or global
variables with the same name, but not pointing to the same object.
- This means that user A can have an instance of class Foo and user B
as well, but they are different classes. Where the difficulty comes in
is that if you encounter instances, which class are you looking at? If
you update the code of Foo, you are updating the code of the class in
your symbol list. This will not affect instances of Foo which are in
the other user's symbol list.
- You may share the UserGlobals symbol dictionaries between users if
you set it up like that.
- Classes are kept concurrently when class definitions are updated
(see classHistory on a class). Migration is a process to get instances
from one class to another. This can be heavy if there are lots of
objects / big database, or you can use the auto migration.

> 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 !?

Yes

> 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 !?

If your 2 CPU's are being eaten up by other things and does not focus
on the computation, then you can do that. But I'd think you must have
a very heavily loaded system with heavy computations to justify that.
I'd build it in Smalltalk and then handle it when I get there.
Alternatively, when you get to that point, it may make sense to buy a
license.

> 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 ?

Yes, class instance variables are better. Some people believe in a
global class that contains your data (perhaps a singleton). I like
have selected classes manage their instances in a class inst var.