Re: Some feedback and a few suggestions

On 8-7-2014 16:30, Mayavimmer wrote:
> Working from the assumption (hehehe) that other people might stumble on 
> the same gotchas that tripped me up (see other thread), here are a few 
> things that would have saved me several hours and much frustration:

Before responding to your issues, let me thank you for your feedback.
I'm always trying to make Pyro as easy to use as possible and improve the documentation
where needed. Sorry if you find yourself in a less than optimal situation, let's hope it
gets better in the near future.

Now abiyt your issues:

> 1. An example of a server with explicit IP address (not localhost).

What you are doing in the code you posted is using the *name server* on an explicit IP
address. This is a special case that is different than using a setup where you directly
connect to your actual pyro server (without the use of a name server).

An example of the latter would be: PYRO:[email protected]:56789
Note the use of PYRO instead of PYRONAME in the Uri.

Your code used "PYRONAME:[email protected]" and what this does is try to
contact the *name server* running on 192.168.56.1 and ask it for the PYRO-uri of the
example.warehouse object.
That is usually not required at all, in most cases you should be able to omit the host
part of a PYRONAME uri because Pyro contains a lookup mechanism that tries to discover
the location of the name server automatically (using a broadcast). As long as the name
server is somewhere in your local subnet it should be found automatically (if you allow
broadcast packets).

See:
http://pythonhosted.org/Pyro4/clientcode.html#object-discovery
http://pythonhosted.org/Pyro4/nameserver.html#locating-the-name-server-and-using-it-in-your-code
http://pythonhosted.org/Pyro4/nameserver.html#the-magical-pyroname-protocol-type

I do agree that the option of including a ip address/port number in a PYRONAME uri is
not put forward well in the documentation, and I will improve this.


> 2. An exact equivalence between SimpleServer and the explicit calls to 
> the Daemon contructor with host parameter, daemon.register, ns.register. 
> (This clears up the business of having the IP included in the published 
> name, which CANNOT be set there, but in the Daemon constructor!)

Why would you want the ip address included in the actual object name?
Other than that: agreed, this should be improved in the docs.


> 3. Daemon and NameServer not having the same method name "register".

Why does this bother you? Both are methods that do something similar, but are not the
same. IMO it's described pretty thoroughly here:
http://pythonhosted.org/Pyro4/servercode.html?highlight=register#Daemon.register


> 4. An example of how to persist a Pyro object with Shelve or ZODB or other.

Pyro objects are not really meant to be persisted by themselves.

Currently, one registers actual objects with Pyro's daemon. Unless you unregister them
(as you found out) Pyro requires that actual object instance to be available to serve
requests. To wire things together it adds a few attributes to the object.
Messing with them will possibly break the daemon. Re-registering an object that already
is or was registered before is currently treated as an error (by design). I can look
into this to see if this is a restriction that could be relaxed a bit.

In your previous mails you wrote "It would appear that nobody has used Pyro with
persistence!". This is not true, people are just not persisting the actual Pyro objects.
The more usual pattern is to have a single Pyro object that represents your
repository/datastore and use it to manage the persistence. The stuff you give it to
store in the datastore, and what you get back from the datastore, are just regular
Python objects - not Pyro objects.

It's great that you got it working though.

> 5. An example of how a client could disconnect cleanly. Though I suspect 
> a solution exists somewhere buried in the examples.

I think you meant how to shutdown a server cleanly. (Disconnecting a client cleanly is
trivial: exit the with block of the proxy, or call proxy._pyroRelease() explicitly)


The sys.exit(0) that you are doing now in the server, is like pulling the rug from under
your own feet, especially if you're doing it with an object that is used by the Pyro
daemon machinery.

The clean way is to use the deamon's shutdown() method and/or by using a special
loopCondition for the requestLoop() method.
Several examples of this can indeed be found such as in the Pyro4.test.echoserver itself
but also in examples/chatbox/client.py

Will describe this in a bit more detail because this paragraph kinda not mentions it at
all: http://pythonhosted.org/Pyro4/servercode.html#cleaning-up

(the info is there in the docs but scattered)

> 
> Mayavimmer

again thanks for your feedback and I'll have a look about the possible improvements that
I've mentioned above.

Irmen


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft