Hello List,
It seems that the xmlrpc unit is missing from fpc source tree (trunk). Was it renamed (to what) or was it remove (why was that) ?
Thanks,
Ido

Mailing lists / fpc-pascal / 2010-06
21 messages · 5 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Hello List,
It seems that the xmlrpc unit is missing from fpc source tree (trunk). Was it renamed (to what) or was it remove (why was that) ?
Thanks,
Ido
ik wroteIt seems that the xmlrpc unit is missing from fpc source tree (trunk). Was it renamed (to what) or was it remove (why was that) ?
r15346 | michael | 2010-05-30 16:14:18 +0200 (Sun, 30 May 2010) | 1 line Changed paths:
D /trunk/packages/fcl-net/src/httpbase.pp
D /trunk/packages/fcl-net/src/httpclient.pp
D /trunk/packages/fcl-net/src/mkxmlrpc.pp
D /trunk/packages/fcl-net/src/servlets.pp
D /trunk/packages/fcl-net/src/xmlrpc.pp
* Deprecated in favour of fcl-web and WST
How to find this sort of information:
cd fpc
svn log -v |less
/xmlrpc
Jonas
Thanks,
I do not understand how do I create an xmlrpc server using fcl-web
Ido
ik wroteThanks, I do not understand how do I create an xmlrpc server using fcl-web
0. Start an fcl-web application.
1. Create an interface and an implementation using WST. (WST has plenty of examples. Easiest is to define an interface MyInterface = Interface ['guid']
end;
and run ws_helper to create metadata, proxy and binder. Add these units
to your project.2. Register the XML-RPC streaming method.
3. Create and register a WSTWebModule.
See the demo that comes with WST on how to do that.
That's it.
Michael.
r15346 | michael | 2010-05-30 16:14:18 +0200 (Sun, 30 May 2010) | 1 line Changed paths: D…
Op 2010-06-30 18:00, Jonas Maebe het geskryf:
* Deprecated in favour of fcl-web and WST
In all fairness, deprecated normally means it is "marked" as deprecated at least for one release *before* it gets deleted. If I was ik, I'd be pretty pissed off working on a project that might be released in a week or two. Already tried and tested and passed QA, and then suddenly need to switch to an unfamiliar technology that has not passed our QA yet. Just my 2c worth.
How to find this sort of information: cd fpc svn log -v |less /xmlrpc
Or if you were using the Git mirror:
$ git log -Sxmlrpc --name-status-S searches the actual patch (code) committed.
--name-status lists the actual files that matched the search term
Regards,
- Graeme -
In our previous episode, Graeme Geldenhuys said:
Fixes still contains it. Most of the fpweb changes are not merged back to 2.4.x
See
http://www.stack.nl/~marcov/fpctomerge.txt
or whatever you generate with GIT for this.
Op 2010-06-30 18:00, Jonas Maebe het geskryf: In all fairness, deprecated normally means…
True, but given that the examples didn't compile since many, many years, I'd say that the probability that xmlrpc passed the QA in a company was very remote indeed. That was why we decided to remove it since the code was not being maintained anyway, he could just have kept the latest copy of it: so no harm done.
Michael.
In our previous episode, Graeme Geldenhuys said: Fixes still contains it. Most of the…
Op 2010-07-01 09:15, Marco van de Voort het geskryf:
Fixes still contains it. Most of the fpweb changes are not merged back to 2.4.x
As usual you don't understand me correctly, as your above statement proves. Let me explain again. The r15346 should not be merged to 2.4.x yet, the code in 2.4.x should FIRST be marked as deprecated for one release (maybe even as soon as FPC 2.4.2 seeing that the 'deprecated' hint directive doesn't break anything). Then only in the NEXT release should r15346 be merged, resulting in those units being removed.
Regards,
- Graeme -
True, but given that the examples didn't compile since many, many years, I'd say that the…
Op 2010-07-01 09:33, Michael Van Canneyt het geskryf:
And since the code was not being maintained anyway, he could just have kept the latest copy of it: so no harm done.
Either way, see my reply to Marco. Your actions might have been ok for Trunk, but definitely will not be for the stable "fixes" branch.
Regards,
- Graeme -
True, but given that the examples didn't compile since many, many years, I'd say that the…
Actually I have a code in PHP that does XMLRPC and a new CentOS installation crashes PHP without any given reason (glib error on an existed code that works on other servers), and I prefer to use something stable and fast rather then something that is not, because I do not have a lot of time to make things work properly (the life of freelancing).
I remembered that FPC have an XMLRPC generator that allow me to just focus at the task I require, and wanted to use it, but the generator could not be compiled because of the missing unit.
I still do not understand (at all) how fpWeb works, and all the examples works with JSON only (I wish I could use it, but the spec files of my client uses XML-RPC), and even Lazarus is unable to properly work with it (some files are missing even after adding fpWeb package to Lazarus), so it does not help much :(
For now I'll add another JVM running and make it a server (because I can do it very quickly) but when I'll have more time to learn fpWeb I would really want to move away from Java + PHP in this cases to FPC in my client production servers.
Ido
Op 2010-07-01 09:44, ik het geskryf:
existed code that works on other servers), and I prefer to use something stable and fast rather then something that is not, because I do not have a lot of time to make things work properly (the life of freelancing).
This is exactly the point I was trying to make. I don't use XML-RPC, but I am arguing the way the change was handled (and the same way proposed for Fixes branch). The Fixes branch must at least be treated with more care that the Trunk branch - give end-user developer more time to adjust there code and learn new technologies if needed. I'm pretty sure we are all very busy (I know I am), so instantly being forced to use something you don't know is not a very nice thing to do.
Regards,
- Graeme -
Actually I have a code in PHP that does XMLRPC and a new CentOS installation crashes PHP…
Where is this generator ? I should remove it too.
In each case the stable branch still contains it. Copy it from there, and be warned: it is no longer supported.
As for fp-web being json: There is nothing JSON specific about WST, on the contrary, I would say ? I am still looking into getting a more leight-weight implementation of xml-rpc in fp-web directly, as WST is sometimes a bit heavy for simple things.
If you experience problems compiling the lot, let me know, I'll see what I can do to help. Be warned that fpweb development is strictly in trunk.
Michael.
Op 2010-07-01 09:33, Michael Van Canneyt het geskryf: Either way, see my reply to Marco.…
That's why I work only in trunk.
And as I understood it, Marco explicitly mentioned that it is not merged back to fixes.
It also does not appear in http://www.stack.nl/~marcov/fpctomerge.txt
Michael.
Op 2010-07-01 09:15, Marco van de Voort het geskryf: As usual you don't understand me…
In our previous episode, Graeme Geldenhuys said:
(or at all)
the code in 2.4.x should FIRST be marked as deprecated for one release (maybe even as soon as FPC 2.4.2 seeing that the 'deprecated' hint directive doesn't break anything).
We all know that, but we don't do that for a reason:
Unit level deprecated is 2.5.1 functionality (r14767 , Mantis 13373)
Still, comments could be added and procedures/methods flagged. I'll take care of this. I also added to user changes trunk.
Michael, please have a look and expand on it:
http://wiki.freepascal.org/User_Changes_Trunk
Then only in the NEXT release should r15346 be merged, resulting in those units being removed.
Units are generally only removed between major releases. I'm not so sure this will since the mutation rate of the new stuff is still high.
As you can see in http://www.stack.nl/~marcov/fpctomerge.txt or your local GIT equivalent, most of the fcl-web/json stuff is not merged.
Where is this generator ? I should remove it too. In each case the stable branch still…
The generator does not exists anymore, the example of svrclass_xmlrpc requires it under:
fpc/packages/fcl-net/examples
The names are misleading then :(
WST is webdata am I correct ?
If you experience problems compiling the lot, let me know, I'll see what I can do to help. Be warned that fpweb development is strictly in trunk.
Thanks, I hope I'll be able to touch it in several weekends from now to test and learn it properly.
Ido
That's why I work only in trunk. And as I understood it, Marco explicitly mentioned that…
Michael Van Canneyt wroteAnd as I understood it, Marco explicitly mentioned that it is not merged back to fixes. It also does not appear in http://www.stack.nl/~marcov/fpctomerge.txt
You do you mean, I clearly see it listed in fpctomerge.txt (I just double checked).
In our previous episode, Graeme Geldenhuys said: (or at all) We all know that, but we…
My apologies, I didn't know unit level deprecated doesn't work in fixes branch. I was just about to comment on this (after I tried it myself and it failed), when I saw your reply.
Still, comments could be added and procedures/methods flagged. I'll take care of this. I also added to user changes trunk.
Maybe adding it as a {$warning This unit is deprecated} will suffice for now, until r14767 is merged with 2.4.x. I just tested {$warning ...} below the 'unit ...;' line, and indeed it does output a warning in the compiler output.
In our previous episode, Graeme Geldenhuys said:
I already added text to the source headers and a "deprecated" modifier to all constructor.
We also want this to show if people use precompiled units :-)
The generator does not exists anymore, the example of svrclass_xmlrpc requires it…
I'll remove that too.
Ah, nono. WST is Webservices Toolkit. You can find it on lazarus-ccr. It can exist completely without lazarus, though. very good and stable product. It works since years. The support for fcl-web is rather recent, though. you can also use it without fcl-web, just with synapse, apache or even indy.
Michael.
You do you mean, I clearly see it listed in fpctomerge.txt (I just double checked). -…
Graeme Geldenhuys wrote on Thu, 01 Jul 2010:
The fpctomerge.txt file is a bit badly named. It simply contains all revisions in trunk that are not in the fixes branch. There is no list of revisions that are scheduled to be merged.
Jonas
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
In our previous episode, Jonas Maebe said:
(strictly speaking it lists the one that are available for merging, so all revisions-already merged - blocked ones . But we haven't done much blocking recently)