yeah, this is one area where xtra time to tinker around would be
great... Here's what I do and where web2py has made my life easier
(using this part with the DAL as stand alone, but same would apply
with an online instance as well).
I re-purposed an app I put together a few years back where one of the
key elements I wanted today was the distributed queuing for
accomplishing distributed tasks. This back end stuff (with the full
web2py as the front end) needs to share large chunks of data, and
since xmlrpc can't't do job 1/2 the time, my first idea (form a few
years back) was to split the data in a way to make all the pieces
stand on its own (like instead having the full recipe for cheese cake,
I compartmentalized the instructions I.e. 1. gather ingredients [you
will need items from this list], 2. make the dry mix [here is the list
of dry ingredients, ask whoever was asked to gather them to send them
to you], 3. make the wet mix [same as item 2] 4. grease the pan [you
will need these items], etc... then all would send back results.
Worked well enough. Now, I do a little bit of the same thing, but more
efficiently. Now when the automation sees that it needs to distribute
a task, it simply sends high level instructions by broadcasting a
"todo" list. available servers (all sitting on a web2py framework),
take on the items on the list, they already know where to go for the
details on the task: All the required data to fulfill the task (even
if user controlled) sits in a central SQLite DB which lives along side
an xmlrpc socket server where all servers can access using the web2py
dal. With that I can use a web2py app to query result, status or
launch another task manually or setup up a task to be available
through automation.
So, the moral: where I can't send a server some data, I tell it where
to get it. So, that said, If I were to need to send PDFs, i would send
them as chunks and reassemble at the other end (provided that server
has the means to reassemble). an example close to this: when the
system was tasked with sending large filesets across sites (like tar
balls), it would send local servers the instruction to extract the
large tar ball (if the size reached a given threshold), then provide
the contributing servers with a list of which bits of the tar ball
they would push to the receiving file server. Then re-tar the contents
at the other end...
But, I remember a posting (last week maybe?) where someone was
mentioning some sort of lib where this may be usefull (I remember
thinking "sounds a little like execnet")... Perhaps Massimo can recall
the post? - when suggesting that web2py make use of the lib, you said
you were already looking at it...
Anyways, hope it helps
Mart :)
On Nov 24, 1:46 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I have had similar problem before. xmlrpclib cannot stream data so I
> cannot handle large content such as a file attachment.
>
> On Nov 24, 12:28 pm, António Ramos <ramstei...@gmail.com> wrote:
>
> > Hello,
> > Is it possible to send an attachment from a python program to an web2py app
> > via xmlrpclib?
>
> > I have a working app with xmlrpc exposed
>
> > i have a python program that has this code
>
> > import xmlrpclib
> > server =
> > xmlrpclib.ServerProxy('http://127.0.0.1:8000/BlaBlaBla/default/call/xmlrpc')
>
> > what do i have to add to send a pdf file for example to BlaBlaBla app ?
>
> > Best regards
>
> > António
>
>
