On Saturday, February 18, 2017 at 6:00:23 AM UTC-8, Anthony wrote:
>
> Do you have a use case that cannot easily be accommodated by that pattern?
>> If so, what do you imagine would be the API for doing what you want to do,
>> and would it look much different from simply making an HTTP call (or
>> possibly an RPC call) to the other app (which you can already do)?
>>
>
> And just to be clear, if you are OK with this:
>
> def order_plain():
> othermod = gluon.shell.exec_environment(
> 'applications/test_env/controllers/db_worker.py')
> return "Hello", othermod.work_plain()
>
> then why not this:
>
> def order_plain():
> work_plain_response = gluon.tools.fetch(URL('db_worker', 'work_plain',
> host='localhost'))
> return "Hello %s" % work_plain_response
>
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.
In your other message you said:
The workflow of an HTTP request involves things like setting up the
> session, and some of the code (particularly controller code) may depend on
> attributes of the request object. If you want to make what amounts to an
> internal request to another app or controller, it will not be clear what
> elements of the current request to retain (e.g., should the current
> session, request headers, query string, etc. be replicated in the second
> call?).
>
Yeah, that is true. To my mind, though, the point of using something like
Service is to constrain the function's interface so that the situation you
describe won't arise. Instead, the function is supposed to depend only on
the arguments you pass it. However, I can see that it is difficult for
web2py to support this use case, because there is no way to enforce the
restriction that nothing in the code path (i.e., nothing in the model or
controller code) directly accesses the request object. In some sense, even
my function does not really just depend on its arguments, because it still
depends on the global "db" object. What I was hoping is that there is a
way to get stuff like "db" (i.e., global objects I created in my model
code) without the need to have objects like "request" (i.e., global objects
built into web2py). But I see your point: the normal web2py workflow
places no constraints on how code may access request/response/session/etc.
Since these objects are "allowed" to be directly accessed (and even
mutated) from anywhere in user code, trying to call code without them would
probably fail more often than not.
(I mostly included work_plain there just to be able to verify that the db
object wasn't being created. My real use case is more like work_service.)
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. The goal of using Service here is what I mentioned
above: to allow the function's API to be its argument signature, rather
than allowing it to grab arbitrary stuff from the request object. The idea
is that sometimes I do want to actually visit the URL in a browser (or
retrieve it programmatically), and in that case of course a real request
must be generated; but just in case the "request" is actually an internal
call, I would rather have a "shortcut" that doesn't do anything that has to
do with going over the wire.
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. 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.)
Anyway, thanks for your help on this matter, I'll look at modularizing my
db-creation code a bit so that I can more easily create the db in each
module that needs it.
--
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.
