Call PIFR directly
boombatower - October 24, 2008 - 05:47
| Project: | Project issue file testing |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Change PIFT to only be the "server" portion and call PIFR directly.
Format of PIFR XMLRPC request.
pifr.batch.queue($server_key, $batch)
where $batch is an array of files of the format
array(
[nid] => 0,
[cid] => 0,
[filename] => 'basename-without files/issues...'
)
example filename: somefile_0.patch
#1
I've designed by code to work with server keys since it will need to deal with lots of slaves and such...the keys will add security as they act like a login.
As part of the xmlrpc request is the server_key which will need to be set on t.d.o and d.o...as I have it coded each server has there own so d.o which it will send with the batch of files to be tested...
t.d.o will sends its own key back to d.o (which will also need to be stored on d.o)
so two variables of 32 character strings.
#2
i believe it is a mistake to do it this way, since both the files directory and the issues directory are configurable. PIFT currently sends the full URL of the patch file -- can you adjust your code to this style?
otherwise, is the $batch array the exact same structure that PIFT has already been sending? looks like it...
#3
Currently my code stores the files directory for each of the servers in a table so that it doesn't have to pass around the elongated paths. I could change it, but I don't see why it is necessary.
#4
this just seems error prone to me. the server sending the files will always know what it's files and issues directories are.
i'm not sure why passing around the full URL is cumbersome?
#5
attached has been committed to 5.x and HEAD. note that i did not alter the format of the $batch array at all from the original PIFT format -- i'm pretty sure that we want to send the full patch URL as i have suggested before.
i've moved to using the server keys as you requested.
--project followup subject--
Automatically closed -- issue fixed for two weeks with no activity.
#6
Automatically closed -- issue fixed for two weeks with no activity.