> If I understand right, the second one generates an HTTP request. That > means the data that is fetched will be serialized and deserialized. In > some cases this data is sizable, so I want to avoid that overhead. There > will likely also be some overhead associated with actually > sending/receiving the network request; this is probably smaller but I'd > still rather avoid it. As I understand it, these operations will also > happen with an RPC call. That's why I keep saying that I don't want an > HTTP request. I want everything to happen totally internally, within the > same request, same process, same everything, nothing going over the wire. >
Correct, there would be some overhead due to the HTTP request. > Because work_service is defined as a JSON-RPC service, the proper way to >> call it would be via an RPC call, as explained here: >> http://web2py.com/books/default/chapter/29/10/services#Accessing-JSONRPC-services-from-web2py >> >> <http://www.google.com/url?q=http%3A%2F%2Fweb2py.com%2Fbooks%2Fdefault%2Fchapter%2F29%2F10%2Fservices%23Accessing-JSONRPC-services-from-web2py&sa=D&sntz=1&usg=AFQjCNE_mUALr04ow2hgCu_eFPifYZfriQ>. >> >> Otherwise, there is not much point in making it an RPC service. >> > > It's not an RPC service per se. The decorator is @service.json, not > @service.jsonrpc. > Oh, right, sorry about that. The same reasoning applies, though -- you would simply make an HTTP request rather than use an RPC client. > That is also why it's not purely a matter of "common functionality that is > shared across apps". Rather, there is functionality that I want to be > accessible BOTH as a "real" URL endpoint AND internally between apps --- > but without the request overhead in the latter case. > I suppose it would help to understand your real world use case. It's not clear what the problem is with using modules. It might also help to know how you would handle this in other frameworks. > So I do want a controller that exposes the function. (I could of course > write a "dummy" controller function that just calls a "worker" function in > a module, but that is essentially what Service already gives me.) > Not exactly. The functions exposed by Service are not accessible as HTTP request endpoints on their own. Note, if you have a lot of functions in a module that all need to be exposed as controller endpoints, you could route to them via request.args. For example, in /modules/mycontroller.py: from gluon import current def myfunc(): return dict(message=current.request.vars.message) And in /controllers/default.py: import mycontroller def index(): return getattr(mycontroller, request.args(0))() Then access /myapp/default/index/myfunc to get the output of myfunc (you can use the router to hide "default" and "index", so the URL can be re-written to /myapp/myfunc). You can put as many functions as you want in mycontroller.py, and they can be accessed from any app. Here is an example of this approach: https://github.com/TechEmpower/FrameworkBenchmarks/tree/2623eae7135205c8ca4da27d44ea1ccda6c19a56/frameworks/Python/web2py/app/standard. Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
