Transport Sample Protocol - Tasks: task #5703, Implement XML-RPC command channel
You are not allowed to post comments on this tracker with your current authentication level.
task #5703: Implement XML-RPC command channel
Submitter: | Eric NOULARD <erk> | ||
Submitted: | Thu 06 Jul 2006 07:46:08 AM UTC | ||
Category: | tsp core | Should Start On: | Wed 05 Jul 2006 10:00:00 PM UTC |
Should be Finished on: | Wed 05 Jul 2006 10:00:00 PM UTC | Priority: | 5 - Normal |
Status: | In Progress | Privacy: | Public |
Percent Complete: | 90% | Assigned to: | sgalles |
Open/Closed: | Open | Effort: | 0.00 |
( Jump to the original submission )
Wed 28 Feb 2007 09:12:45 AM UTC, comment #10: |
Eric NOULARD <erk>![]() |
Tue 27 Feb 2007 01:36:08 AM UTC, comment #9: I just wanted to add that I left the task at 90% because there's still something to be modified in order to have the XMLRPC channel display its URL on stdout when the provider is started. For now, only the RPC channel displays its URL, the XMLRPC channel displays an empty URL (nevertheless everything is perfectly functional)
|
Stephane GALLES <sgalles>![]() ![]() |
Mon 26 Feb 2007 10:33:18 PM UTC, comment #8: Nice work, indeed!
Are such places defined anywhere?
|
Frederik Deweerdt <deweerdt>![]() |
Mon 26 Feb 2007 09:55:52 PM UTC, comment #7: Simultaneous XML-RPC + ONC-RPC is just great!!!
|
Eric NOULARD <erk>![]() |
Mon 26 Feb 2007 07:35:20 PM UTC, comment #6: commited : When the compilation with the XMLRPC channel is ON, the RPC channel is not turned off anymore (both can be used simultaneously). |
Stephane GALLES <sgalles>![]() ![]() |
Tue 20 Feb 2007 09:12:19 PM UTC, comment #5: offset supporté dans la partie XMLRPC, et dans la partie Ruby. Reste à pouvoir compiler en même temps la canal XMLRPC et le canal RPC |
Stephane GALLES <sgalles>![]() ![]() |
Mon 14 Aug 2006 03:39:26 AM UTC, comment #4: Dans le code du serveur XMLRPC j'ai ajouté le renvoi du type, ce qui m'a permis de faire fonctionner le multi - type dans le client Ruby. Bientot les tableaux. |
Stephane GALLES <sgalles>![]() ![]() |
Wed 19 Jul 2006 11:32:32 AM UTC, comment #3: Au fait, J'ai ajouté une CMakeLists.txt pour le tsp_stub_server qui n'en avait pas. Justement parceque l'exemple de Rubytsp est fait pour fonctionner avecle tsp_stub_server. |
Stephane GALLES <sgalles>![]() ![]() |
Wed 19 Jul 2006 07:46:42 AM UTC, comment #2: Cool,
|
Eric NOULARD <erk>![]() |
Wed 19 Jul 2006 12:55:23 AM UTC, comment #1: Le merge du patch de fred est fait. La compilation peut se faire avec
|
Stephane GALLES <sgalles>![]() ![]() |
Thu 06 Jul 2006 07:46:08 AM UTC, original submission:
La tache a ete commencee by Fred. D il y a de ca quelques temps
http://www.mail-archive.com/tsp-devel@nongnu.org/msg00321.html
|
Eric NOULARD <erk>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
I agree with those locations with some
others like:
/opt/tsp/plugins
$HOME/.tsp/plugins
$TSP_PLUGINS_PATH if it is defined.
We should agree for search order to
be able to handle priority
I would suggest:
$TSP_PLUGINS_PATH
$HOME/.tsp/lib
$HOME/.tsp/plugins
/opt/tsp/plugins
/opt/tsp/lib
Those PATH and env var may (?should?) be used
for all kind of TSP forthcoming plugins
(BB plugins, Targa Plugins, TSP Core plugins).
Yes I agree with this scheme, but we should handle
the case of multiple instance of same lib found
in several places something more like:
for each (dir)
try to open a lib named librequest_XYZ.so
liblist.add_if_unique(librequest_XYZ.so)
..
then go on with previous process.
we should agree on naming convention for those lib/plugins.
As a sidenote I designed "request handler API"
in order to be able to 'hot-add' request handler
the idea is to trigger dyn lib load with something
like a SIGHUP handler (like most daemon do)
that would rescan for no already
loaded dynlib and then call
TSP_provider_rqh_manager_refresh
If we want to achieve this (which may be too much :))
the process should include a test in order to avoid
to load the same library twice.
In the end since this mechanism is clearly DANGEROUS for
the average real time provider, the default behavior should
be not to handle the "hot-plug" behavior.