[turba] how to save a photo through the api --> rpc request

roman stachura stachrom at gmail.com
Wed Oct 29 15:19:00 UTC 2008


Jan Schneider schrieb:
> Zitat von roman stachura <stachrom at gmail.com>:
>
>> Jan Schneider schrieb:
>>> Zitat von roman stachura <stachrom at gmail.com>:
>>>
>>>> Jan Schneider schrieb:
>>>>> Zitat von roman stachura <stachrom at gmail.com>:
>>>>>
>>>>>> Michael Rubinsky schrieb:
>>>>>>> Quoting roman stachura <stachrom at gmail.com>:
>>>>>>>
>>>>>>>> Jan Schneider schrieb:
>>>>>>>>> Zitat von roman stachura <stachrom at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Jan Schneider schrieb:
>>>>>>>>>>> Zitat von Michael Rubinsky <mrubinsk at horde.org>:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Quoting roman stachura <stachrom at gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wonder how can I  save binary data like a photo through 
>>>>>>>>>>>>> a rpc request under the turba api from a external server.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How should I compose the $rpc_parameters_turba_import array ?
>>>>>>>>>>>>
>>>>>>>>>>>> After a quick glance at the code, it doesn't look like this 
>>>>>>>>>>>> is currently possible.  The binary data will need to be 
>>>>>>>>>>>> encoded before it is sent over jsonrpc, but the 
>>>>>>>>>>>> _turba_import method doesn't currently check for this and 
>>>>>>>>>>>> decode it. We'll have to add support for encoded binary 
>>>>>>>>>>>> data to the import method, and a way to hint at what the 
>>>>>>>>>>>> encoding type is. How to do that in a BC way though?
>>>>>>>>>>>
>>>>>>>>>> Tanks for the quick answer.
>>>>>>>>>>
>>>>>>>>>>> It doesn't work with xmlrpc or jsonrpc, but it should, 
>>>>>>>>>>> theoretically, work with SOAP.
>>>>>>>>>> Is there a SOAP example around for a php client?  (in general 
>>>>>>>>>> not specificly for turba.)
>>>>>>>>>> So I can give SOAP a try.
>>>>>>>>>
>>>>>>>>> http://cvs.horde.org/co.php/framework/RPC/tests/rpc-test.php?r=1.8 
>>>>>>>>>
>>>>>>>>> http://cvs.horde.org/co.php/framework/RPC/docs/examples/soap.php?r=1.2 
>>>>>>>>> http://cvs.horde.org/co.php/framework/RPC/docs/examples/soap.pl?r=1.1 
>>>>>>>>> You probably have to explicitly pass the binary data as a 
>>>>>>>>> SOAP_Value object:
>>>>>>>>> http://pear.php.net/package/SOAP/docs/latest/SOAP/SOAP_Value.html#methodSOAP_Value 
>>>>>>>>>
>>>>>>>> I guess this requires at least php5.
>>>>>>>
>>>>>>> Why do you say that?
>>>>>>
>>>>>> Either I got a badly broken horde install (soap server) or I miss 
>>>>>> something else.
>>>>>> If I go for a soap request under php 5 things work well.
>>>>>> If I do the same request on a php4 horde install things turn 
>>>>>> really bad.
>>>>>>
>>>>>> php 5 http://webmail.cmdbase.ch/test.php
>>>>>> php 4 http://horde.akero.ch/test.php
>>>>>>
>>>>>> and the result for php4 box : 
>>>>>> http://entwicklung.akero.ch/example/soap.php
>>>>>
>>>>> Ignore the warning for now, you probably just have different error 
>>>>> levels set on your php4 and php5 installs. But the SOAP fault 
>>>>> message is crystal clear.
>>>>>
>>>>
>>>> I do have exact the same level of error reporting and I do the SAME 
>>>> request, no changes in the  number of parameters. At this point of 
>>>> view the SOAP fault is not so crystal clear to me...
>>>> Anyway I added the two missing arguments like requestet by SOAP fault.
>>>>
>>>> $rpc_arguments = array(
>>>> 'owneronly' => false,
>>>> 'permission' => 0
>>>> );
>>>>
>>>> this leads me to the next problem.
>>>>
>>>>
>>>> http://entwicklung.akero.ch/example/soap.php --> 
>>>> SOAP-ENV:WSDLPARSER Unable to parse WSDL file.
>>>
>>> And how *does* the WSDL look like?
>> well formed... the way i should.  I don't get the point.
>
> Me neither, that's weird.
logfile output:
Oct 29 15:53:50 HORDE [info] [horde] SOAP call: calendar/listCalendars(, 
0) by test serviced in 0 seconds, sent 747 bytes in response [pid 3976 
on line 214 of 
"/home/www/htdocs/kunden/horde/htdocs/lib/Horde/RPC/soap.php"]
As i work on virtual host i double checked the host entry in the 
/etc/hosts file...  the virtual host  "horde.akero.ch"  is resolving 
internal on 192.168.1.8. This should be right.
>
> Jan.
>



More information about the turba mailing list