shared/distributed objects

How do implement shared/distributed objects with dolphin.I mean something
like  client - server traditional configuration.
I am thinking in a multiuser system where the users can use the same Object
( may be invoice ) in diferent location or make CRUD
of objects. The only way I can imaging this is by ODBMS or RDMS. there is
another way like sharing partly an image?
TIA

"pablo digonzelli" <[hidden email]> wrote in message
news:95ukgb$itste$[hidden email]...
> How do implement shared/distributed objects with dolphin.I mean something
> like  client - server traditional configuration.
> I am thinking in a multiuser system where the users can use the same
Object
> ( may be invoice ) in diferent location or make CRUD
> of objects. The only way I can imaging this is by ODBMS or RDMS. there is
> another way like sharing partly an image?

David Gorisek's OmniBase (OODB) add-in for Dolphin sounds like it would be
one approach.  I believe it costs around $150 and allows you to use it
royalty-free in applications you distribute (and that a no-charge evaluation
version is available).  One characteristic of it which I think may be a
drawback in certain cases is that it requires all the clients to use a
shared file system.  If you try it out, please report how it works out for
you, as I am curious.

If OmniBase had been available at the time and if I had known about it,
etc., I might well have used it for the application I have been rewriting in
Dolphin.  Instead, I am using a database server I wrote in Python, which is
a wrapper around the free MetaKit database, combined with Object-Relational
mapping code I wrote for the Smalltalk side (based on the scheme discussed
in Chamond Liu's book).  I am very happy with MetaKit and with Python.  The
clients communicate with the server via TCP/IP.  An advantage this approach
gives me is that I *could* run the server on a Linux box.  Thus, even though
I am tied to Windows for the client (because Dolphin runs on Windows only),
for the part of the system where a more reliable operating system is *most*
needed, I am not tied to Windows.

On the other hand, there is a certain stress on me when I leave my lovely
Smalltalk environment to work in the Python environment.  I need to do this
so seldom that I forget what I was doing in the Python and have to re-orient
myself (and, without the Smalltalk tools to help me).  Whenever I do this
(and I am doing this *today*), I wish I had written a simpler system in
Python, which would never need changing, that I would control from
Smalltalk.  Each time, I ask myself whether today is the day I should remedy
this situation but so far I have answered that it is cheaper to continue as
is.

But, an alternative I have been thinking of was inspired by some recent
posts by Nevin Pratt (either in comp.lang.smalltalk or on the XP mailing
list).  He recommended pushing further and further toward building very
simple GUIs with everything that could possibly be done in the model removed
from the GUI.  He went as far as recommending no converters for text entry
fields in the GUI but to set them to handle just strings.  Plain strings
would be sent to the model which would reformat as appropriate and send
plain strings back to the text entry fields.  (This didn't completely answer
my concern about checkboxes, radio buttons, etc., which I don't want to give
up (and I don't think Nevin was recommending giving them up).)

So, what this leads me to is the idea of Dolphin the server versus Dolphin
the client, where the client part of your application is a simple browser
(yes, much like Internet Explorer, but perhaps dumber).  Actual objects
(domain objects) would live only on the server.  Only their displayStrings
(so to speak) would ever get sent to the client.  Thus, the clients would
fully share the image, as there would be only one image.  Well, of course,
the client has its own image but it provides a general browser application
and knows nothing of your domain objects.  Why not use a real web browser
instead?  I think I want more control over the UI than a web browser
provides.

(Maybe the Dolphin web plug-in provides exactly the above?  I don't know.  I
would love to see some discussion about it, as I have found it hard to dig
in to get a feel for just what it does and where and how it could be used.)


-- Frank
[hidden email]
What if doing the Hokey-Pokey really *was* what it was all about?

I'm using OmniBase on a project I'm currently working on, and I really enjoy
it.  It has taken me some time to get used to thinking inside of
transactions, but I believe I am mostly over that hurdle now.   I've used
transaction before in Delphi, but the experience is very different here.

I have found that OmniBase out-of-the-box allows you lots of flexibility on
how to structure your application, and I'm building a set of objects that
help me work in the way that looks best to me so far.

You'll probably find some things missing in OmniBase - you will basically
have to handle your own indexing and searching in some way or another.
Personally, I plan to handle full-text searches by adding a resource to the
Swazoo web application server which will walk the OmniBase database and
create a set of HTML pages which MS Search will then index.

STS is the source tracking system, also by David Gorisek.  It is a great
example of the kinds of things you can build with OmniBase- I use it
religiously and it has saved my butt more than once.

Also note that the fact that OmniBase is reliant on the file system actually
works well for your Linux server- just run Samba and put the OmniBase files
on the Linux box- you don't need an actual server process running with
OmniBase.

Jerry Bell
[hidden email]

"Frank Sergeant" <[hidden email]> wrote in message
news:4tEg6.938$[hidden email]...
>
> "pablo digonzelli" <[hidden email]> wrote in message
> news:95ukgb$itste$[hidden email]...
> > How do implement shared/distributed objects with dolphin.I mean
something
> > like  client - server traditional configuration.
> > I am thinking in a multiuser system where the users can use the same
> Object
> > ( may be invoice ) in diferent location or make CRUD
> > of objects. The only way I can imaging this is by ODBMS or RDMS. there
is
> > another way like sharing partly an image?
>
> David Gorisek's OmniBase (OODB) add-in for Dolphin sounds like it would be
> one approach.  I believe it costs around $150 and allows you to use it
> royalty-free in applications you distribute (and that a no-charge
evaluation
> version is available).  One characteristic of it which I think may be a
> drawback in certain cases is that it requires all the clients to use a
> shared file system.  If you try it out, please report how it works out for
> you, as I am curious.
>
> If OmniBase had been available at the time and if I had known about it,
> etc., I might well have used it for the application I have been rewriting
in
> Dolphin.  Instead, I am using a database server I wrote in Python, which
is
> a wrapper around the free MetaKit database, combined with
Object-Relational
> mapping code I wrote for the Smalltalk side (based on the scheme discussed
> in Chamond Liu's book).  I am very happy with MetaKit and with Python.
The
> clients communicate with the server via TCP/IP.  An advantage this
approach
> gives me is that I *could* run the server on a Linux box.  Thus, even
though
> I am tied to Windows for the client (because Dolphin runs on Windows
only),
> for the part of the system where a more reliable operating system is
*most*
> needed, I am not tied to Windows.
>
> On the other hand, there is a certain stress on me when I leave my lovely
> Smalltalk environment to work in the Python environment.  I need to do
this
> so seldom that I forget what I was doing in the Python and have to
re-orient
> myself (and, without the Smalltalk tools to help me).  Whenever I do this
> (and I am doing this *today*), I wish I had written a simpler system in
> Python, which would never need changing, that I would control from
> Smalltalk.  Each time, I ask myself whether today is the day I should
remedy
> this situation but so far I have answered that it is cheaper to continue
as
> is.
>
> But, an alternative I have been thinking of was inspired by some recent
> posts by Nevin Pratt (either in comp.lang.smalltalk or on the XP mailing
> list).  He recommended pushing further and further toward building very
> simple GUIs with everything that could possibly be done in the model
removed
> from the GUI.  He went as far as recommending no converters for text entry
> fields in the GUI but to set them to handle just strings.  Plain strings
> would be sent to the model which would reformat as appropriate and send
> plain strings back to the text entry fields.  (This didn't completely
answer
> my concern about checkboxes, radio buttons, etc., which I don't want to
give I
> would love to see some discussion about it, as I have found it hard to dig
> in to get a feel for just what it does and where and how it could be
used.)
>
>
> -- Frank
> [hidden email]
> What if doing the Hokey-Pokey really *was* what it was all about?
>
>
>

"Jerry Bell" <[hidden email]> wrote in message
news:95v9lk$iqgl6$[hidden email]...
> I'm using OmniBase on a project I'm currently working on, and I really
enjoy
> it.

Thanks for your feedback on OmniBase.

> You'll probably find some things missing in OmniBase - you will basically
> have to handle your own indexing and searching in some way or another.

I thought it had some sort of b-tree class with which you could build
indexes.  My impression was that you would need to do that explicitly,
rather than relying on the database to do that for you behind the scene.
I've just barely glanced at the demo version.  Ah, here is what I was
thinking of

     OmniBase>>newBTreeDictionary:
     OmniBase>>newBTreeIndexDictionary:

but I haven't looked closely.  I just assumed they allowed you to set up
your own indexes somehow.

> Also note that the fact that OmniBase is reliant on the file system
actually
> works well for your Linux server- just run Samba and put the OmniBase
files
> on the Linux box- you don't need an actual server process running with
> OmniBase.

Thanks.  I hadn't thought of that.  I suppose this would work even with a
remote file system (a network file system), although I guess we'd need to
see what the performance was like in such a case.  I'd like to look into
that further (but I don't know when I'll find the time).

-- Frank
[hidden email]
Never drink before noon, my father said.  Then he said it is always after
noon somewhere.

> But, an alternative I have been thinking of was inspired by some recent
> posts by Nevin Pratt (either in comp.lang.smalltalk or on the XP mailing
> list).  He recommended pushing further and further toward building very
> simple GUIs with everything that could possibly be done in the model
removed
> from the GUI.  He went as far as recommending no converters for text entry
> fields in the GUI but to set them to handle just strings.  Plain strings
> would be sent to the model which would reformat as appropriate and send
> plain strings back to the text entry fields.  (This didn't completely
answer
> my concern about checkboxes, radio buttons, etc., which I don't want to
give
> up (and I don't think Nevin was recommending giving them up).)

Frank,

This type of separation is a great idea, and it's what we used in our
(on-going) SUnit redesign. It has an engine which is GUI-framework
independent, plus a very light-weight GUI. One reason to choose this design
was to ease the effort of porting to other dialects. As a bonus, it also
allows plugging several synchronized user interfaces onto the same engine.
E-mail me if you want a preview version.

Regarding eliminating GUI-tied-converters, I believe that is the way to go
also. I've already developed several application frameworks that do that.
It's the underlying domain objects which know how to interpret and represent
the user's input. This gives better reuse and lighter weight GUI code.

One of the application frameworks built on the VisualAge user interface
builder, which requires converters, and for that we implemented a generic
converter which acts as a mediator to the interpretation/validation and
presentation code in the domain objects (together with controller/engine
type objects which contain the interaction logic and the GUI-to-model
mapping). The net effect is the same; you don't tie your user interface
controls to specific domain types, and you don't have to write controllers
for every intelligent portable domain value you create.

If you use controllers with mappings, it isn't hard to overcome the issues
with domain objects you can't store into, such as boolean aspects which are
presented as toggle buttons.

Regards,

Peter van Rooijen

Yes, the support is there, but you have to handle updating them yourself.
I'm hoping to generalize that somewhat so I don't have to hard-code index
maintenance into the important ivar setters of my model objects.

Jerry Bell
[hidden email]

> > from the GUI.  He went as far as recommending no converters for text
entry
> > fields in the GUI but to set them to handle just strings.  Plain strings
> > would be sent to the model which would reformat as appropriate and send
> > plain strings back to the text entry fields.  (This didn't completely

To stir up the debate a little<g>, isn't putting string-based methods into a
model that works in floats really just dumping the GUI's problems on the
model rather than the other way around?  Solving the problem "in between"
using adaptors makes sense to me.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:961nki$j76hi$[hidden email]...
> To stir up the debate a little<g>, isn't putting string-based methods into
a
> model that works in floats really just dumping the GUI's problems on the
> model rather than the other way around?

You, too, are right.  On the other hand, model objects typically answer up
to #printString and #displayString.

>  Solving the problem "in between" using adaptors makes sense to me.

Thanks.  I don't disagree.


--Frank
[hidden email]
Money is the root of all evil.  A man needs roots.

Guys ,
I read all the posts of the thread.
Then a decided to start with OmniBase.
It seems be interesting and efficient.I was testing it until i want to read
and modify an object.
I post a very little example that show i can't understand something.
First I create a "database" ans store an object in it.

db := OmniBase createOn: 'c:\temp\xxxx'.
tr  := db newTransaction.
o := Employee new.
o firstName: 'Pablo'.
tr root at: 'Employees' put: OrderedCollection new.
( tr root at: 'Employees' ) add: o.
tr commit.
db close.

Until here , all OK. Then I read the object.

db := OmniBase openOn: 'c:\temp\xxxx'.
tr  := db newTransaction.
x := .( tr root at: 'Employees' ) at: 1.
x inspect. "Obviously firstName was 'Pablo'"

then I change the firstName.

x firstName: 'JUAN'.
( tr root at: 'Employees' ) at: 1 put: x.
tr commit.
db close.

Later I read the object again:

db := OmniBase openOn: 'c:\temp\xxxx'.
tr  := db newTransaction.
j := .( tr root at: 'Employees' ) at: 1.
j inspect.

Here, my surprise was that the firstName was 'Pablo' and not 'JUAN'.
I don't understand why this happend.

Can anyone help me?

TIA.

"Frank Sergeant" <[hidden email]> wrote in message
news:4tEg6.938$[hidden email]...
>
> "pablo digonzelli" <[hidden email]> wrote in message
> news:95ukgb$itste$[hidden email]...
> > How do implement shared/distributed objects with dolphin.I mean
something
> > like  client - server traditional configuration.
> > I am thinking in a multiuser system where the users can use the same
> Object
> > ( may be invoice ) in diferent location or make CRUD
> > of objects. The only way I can imaging this is by ODBMS or RDMS. there
is
> > another way like sharing partly an image?
>
> David Gorisek's OmniBase (OODB) add-in for Dolphin sounds like it would be
> one approach.  I believe it costs around $150 and allows you to use it
> royalty-free in applications you distribute (and that a no-charge
evaluation
> version is available).  One characteristic of it which I think may be a
> drawback in certain cases is that it requires all the clients to use a
> shared file system.  If you try it out, please report how it works out for
> you, as I am curious.
>
> If OmniBase had been available at the time and if I had known about it,
> etc., I might well have used it for the application I have been rewriting
in
> Dolphin.  Instead, I am using a database server I wrote in Python, which
is
> a wrapper around the free MetaKit database, combined with
Object-Relational
> mapping code I wrote for the Smalltalk side (based on the scheme discussed
> in Chamond Liu's book).  I am very happy with MetaKit and with Python.
The
> clients communicate with the server via TCP/IP.  An advantage this
approach
> gives me is that I *could* run the server on a Linux box.  Thus, even
though
> I am tied to Windows for the client (because Dolphin runs on Windows
only),
> for the part of the system where a more reliable operating system is
*most*
> needed, I am not tied to Windows.
>
> On the other hand, there is a certain stress on me when I leave my lovely
> Smalltalk environment to work in the Python environment.  I need to do
this
> so seldom that I forget what I was doing in the Python and have to
re-orient
> myself (and, without the Smalltalk tools to help me).  Whenever I do this
> (and I am doing this *today*), I wish I had written a simpler system in
> Python, which would never need changing, that I would control from
> Smalltalk.  Each time, I ask myself whether today is the day I should
remedy
> this situation but so far I have answered that it is cheaper to continue
as
> is.
>
> But, an alternative I have been thinking of was inspired by some recent
> posts by Nevin Pratt (either in comp.lang.smalltalk or on the XP mailing
> list).  He recommended pushing further and further toward building very
> simple GUIs with everything that could possibly be done in the model
removed
> from the GUI.  He went as far as recommending no converters for text entry
> fields in the GUI but to set them to handle just strings.  Plain strings
> would be sent to the model which would reformat as appropriate and send
> plain strings back to the text entry fields.  (This didn't completely
answer
> my concern about checkboxes, radio buttons, etc., which I don't want to
give I
> would love to see some discussion about it, as I have found it hard to dig
> in to get a feel for just what it does and where and how it could be
used.)
>
>
> -- Frank
> [hidden email]
> What if doing the Hokey-Pokey really *was* what it was all about?
>
>
>

Pablo,

See my answer with explanations of what is happening in your code below:

In article <964b6a$jk6lg$[hidden email]>,
  "pablo digonzelli" <[hidden email]> wrote:
> Guys ,
> I read all the posts of the thread.
> Then a decided to start with OmniBase.
> It seems be interesting and efficient.I was testing it until i want
to read
Here, you've implicitly made a persistent instance of
OrderedCollection. It became persistent only because it's being
referenced from root.


> Until here , all OK. Then I read the object.
>
> db := OmniBase openOn: 'c:\temp\xxxx'.
> tr  := db newTransaction.
> x := .( tr root at: 'Employees' ) at: 1.
> x inspect. "Obviously firstName was 'Pablo'"
>

Here, you are reading a single persistent object i.e. a collection
together with its elements.

> then I change the firstName.
>
> x firstName: 'JUAN'.
> ( tr root at: 'Employees' ) at: 1 put: x.
> tr commit.
> db close.

Here, you're changing the value of an object contained within a
persistent ordered collection. But if you check the chapter where
object clustering is described in OmniBase tutorial you will see that
since the employee object is stored within another persistent object
the transaction has to be notified that the persistent collection of
employees has changed (because one of its elements has changed). But
here it is not being notified of this change. Simply calling #at:put:
will not mark it as dirty, but will make it persistent if it's not
already. That's what happend at the beginning.
It would have worked if you changed #at:put: to:

  tr markDirty: (tr root at: 'Employees').


If your are using class Employee as it is in the PersonnelFiles example
then I suggest that you always use method #newPersistent when creating
new persistent instances. Also, as you can see setter methods are
adapted to detect changes in state and notify transactions accordingly.
In the example there are also indexes implemented using b-tree
dictionaries.

Best regards,

David Gorisek


Sent via Deja.com
http://www.deja.com/

In article <BRMg6.984$[hidden email]>,
  "Frank Sergeant" <[hidden email]> wrote:
>
> "Jerry Bell" <[hidden email]> wrote in message
> news:95v9lk$iqgl6$[hidden email]...
> > I'm using OmniBase on a project I'm currently working on, and I
really
> enjoy
> > it.
>
> Thanks for your feedback on OmniBase.
>
> > You'll probably find some things missing in OmniBase - you will
basically
> > have to handle your own indexing and searching in some way or
another.
>
> I thought it had some sort of b-tree class with which you could build
> indexes.  My impression was that you would need to do that explicitly,
> rather than relying on the database to do that for you behind the
scene.
> I've just barely glanced at the demo version.  Ah, here is what I was
> thinking of
>
>      OmniBase>>newBTreeDictionary:
>      OmniBase>>newBTreeIndexDictionary:
>
> but I haven't looked closely.  I just assumed they allowed you to set
up
> your own indexes somehow.
>

You can view OmniBase almost as a multi-user persistent Smalltalk
image. So as in Smalltalk you've got to do your own indexing using
dictionaries and similar data structures. The other possibility is that
you develop your object model in a way that indexes are not needed and
where everything can be achieved just by navigating relationships
between objects. That's also the area where object databases are
clearly better than relational databases.
In OmniBase you can use special kind of dictionary which uses a multi-
user implementation of a b-tree underneath. So this dictionary can be
simultaneously updated by multiple users at the same time. And the best
thing is that while they are all updating the same object everyone of
them still has its own view of the dictionary as though he was alone
working with it. Only in case two users want to change the same
association will you a locking conflict which is resolved on a FCFS
basis.
An example of how indexes can be implemented can be seen in the example
package that comes with OmniBase evaluation version (see method
Employee>>updateIndexesFor: and Employee class methods #findBy*...).

Best regards,

David Gorisek


Sent via Deja.com
http://www.deja.com/

"Peter van Rooijen" <[hidden email]> wrote in message
news:9606vi$aad$[hidden email]...
> This type of separation is a great idea, and it's what we used in our
> (on-going) SUnit redesign. It has an engine which is GUI-framework
 ...
> E-mail me if you want a preview version.

Thank you.  I will if I get caught up enough, but I'm so swamped at the
moment that I'll probably wait until it's generally available.

> Regarding eliminating GUI-tied-converters, I believe that is the way to go

Thanks for your further notes.


-- Frank
[hidden email]

"David Gorisek" <[hidden email]> wrote in message
news:964i1t$r5b$[hidden email]...
> >      OmniBase>>newBTreeDictionary:
> >      OmniBase>>newBTreeIndexDictionary:
  ...
> You can view OmniBase almost as a multi-user persistent Smalltalk
> image. So as in Smalltalk you've got to do your own indexing using
> dictionaries and similar data structures. The other possibility is that
> you develop your object model in a way that indexes are not needed and
> where everything can be achieved just by navigating relationships
> between objects. That's also the area where object databases are
> clearly better than relational databases.

Thanks (and also to Pablo for asking some questions).  I'm getting a clearer
picture of OmniBase from these discussions.

David, there was an earlier suggestion that OmniBase might work well from a
Linux box (running Samba so the Windows client boxes running Dolphin see it
as just another networked disk drive).  It seems that if it would work that
way it would also work from a *remote* Linux box, as I think Samba runs over
TCP/IP.  Have you had any experience running OmniBase over a fairly slow
connection, such as a modem?


-- Frank
[hidden email]

In article <kvoh6.1228$[hidden email]>,
  "Frank Sergeant" <[hidden email]> wrote:
>
> David, there was an earlier suggestion that OmniBase might work well
from a
> Linux box (running Samba so the Windows client boxes running Dolphin
see it
> as just another networked disk drive).  It seems that if it would
work that
> way it would also work from a *remote* Linux box, as I think Samba
runs over
> TCP/IP.  Have you had any experience running OmniBase over a fairly
slow
> connection, such as a modem?
>
> -- Frank
> [hidden email]
>
>

I haven't tried this yet and the database was also never designed to be
used over a modem connection (phone not cable modem). If the file
access is fast and responsive enough, then it should be no problem for
the database, otherwise I would say we need an optimized OmniBase
server.

Best regards,

David Gorisek


Sent via Deja.com
http://www.deja.com/

Thanks David
Pablo
"David Gorisek" <[hidden email]> wrote in message
news:964hdq$ql7$[hidden email]...

Hi David ,

    Will it be possible to have an option of: "an optimized OmniBase server"
running over TCP/IP in the future. So that We can access OmniBase DB from
anywhere (including Internet ).

Regards
Pearapon S.

If you're using plain old SMB-type file sharing over the internet, you're
going to need to be concerned about traversing firewalls.  Most people block
that sort of thing, so unless you have a lot of control at both ends of the
connection you might have problems.

Not that I have a solution for the problem- just something to think about...

Jerry Bell
[hidden email]


"Pearapon S." <[hidden email]> wrote in message
news:966g01$jtqvt$[hidden email]...
> Hi David ,
>
>     Will it be possible to have an option of: "an optimized OmniBase
server"

"David Gorisek" <[hidden email]> wrote in message
news:965h0n$hjf$[hidden email]...
> I haven't tried this yet and the database was also never designed to be
> used over a modem connection (phone not cable modem). If the file
> access is fast and responsive enough, then it should be no problem for
> the database, otherwise I would say we need an optimized OmniBase
> server.

Ok.  (I'm not sure that I would need it; just thinking.)

-- Frank
[hidden email]

"Frank Sergeant" <[hidden email]> wrote in message
news:9poh6.1226$[hidden email]...
It's now generally available at

www.wikiweb.com/~UnitTesting

Regards,

Peter van Rooijen

On Thu, 8 Feb 2001 15:45:52 -0600,
Frank Sergeant <[hidden email]> wrote:
>If OmniBase had been available at the time and if I had known about it,
>etc., I might well have used it for the application I have been rewriting in
>Dolphin.  Instead, I am using a database server I wrote in Python, which is
>a wrapper around the free MetaKit database, combined with Object-Relational
>mapping code I wrote for the Smalltalk side (based on the scheme discussed
>in Chamond Liu's book).  I am very happy with MetaKit and with Python.

That's very interesting.

Have you tought about using Zope-related technologies (ZODB & ZPublisher in
aprticular) for the server part? You'd get a object database supporting
multiple backends[*] and a thru-the-web server programming interface (actually,
writing a management interface in Dolphin shouldn't be very hard).

[*] Plain ZODB; distributed ZODB thru ZEO; SQL storage with Oracle,
Interbase, Sybase or Postgres; Berkley DBM, etc.

The missing part is a SOAP or XML-RPC or ZPublisher.Client library for
Dolphin. Anyone knowns where I can find one?

If you don't like python, Zope has been adapted to use Perl (ack!)... well,
I'd like to have a GNU Smalltalk-compatible ZODB.

--
Roberto Lupi