Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2010-06

xmlrpc unit

21 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Jonas Maebe
to ik
ik wrote
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) ?

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

Reply by email

ik
to Jonas Maebe

Thanks,

I do not understand how do I create an xmlrpc server using fcl-web

Ido

Jonas Maebe wrote 27 lines
On 30 Jun 2010, at 17:37, ik wrote: > 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) ? 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 _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply by email

Michael Van Canneyt
to ik
ik wrote
Thanks, 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.

Show quoted text 36 lines
Ido On Wed, Jun 30, 2010 at 19:00, Jonas Maebe wrote: > > On 30 Jun 2010, at 17:37, ik wrote: > >> 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) ? > > 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 > _______________________________________________ > fpc-pascal maillist - > http://lists.freepascal.org/mailman/listinfo/fpc-pascal >

Reply by email

Graeme Geldenhuys
to Jonas Maebe: 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 -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Marco van de Voort
to Graeme Geldenhuys

In our previous episode, Graeme Geldenhuys said:

Show quoted text 7 lines
> * 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.

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.

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: Op 2010-06-30 18:00, Jonas Maebe het geskryf: In all fairness, deprecated normally means…
Graeme Geldenhuys wrote 9 lines
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.

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.

Reply by email

Graeme Geldenhuys
to Marco van de Voort: 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 -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: 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 -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

ik
to Michael Van Canneyt: True, but given that the examples didn't compile since many, many years, I'd say that the…
Michael Van Canneyt wrote 26 lines
On Thu, 1 Jul 2010, Graeme Geldenhuys wrote: 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. > 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 alltogether at once.

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.

Show quoted text 11 lines
And since the code was not being maintained anyway, he could just have kept the latest copy of it: so no harm done. Michael. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Ido

Reply by email

Graeme Geldenhuys
to ik

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 -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Michael Van Canneyt
to ik: Actually I have a code in PHP that does XMLRPC and a new CentOS installation crashes PHP…
ik wrote 29 lines
On Thu, Jul 1, 2010 at 10:33, Michael Van Canneyt wrote: >> 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. >> > > 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 alltogether at once. > 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.

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.

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: Op 2010-07-01 09:33, Michael Van Canneyt het geskryf: Either way, see my reply to Marco.…
Graeme Geldenhuys wrote 7 lines
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.

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.

Reply by email

Marco van de Voort
to Graeme Geldenhuys: 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:

Show quoted text 5 lines
> 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,

(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.

Reply by email

ik
to Michael Van Canneyt: Where is this generator ? I should remove it too. In each case the stable branch still…
Michael Van Canneyt wrote 41 lines
On Thu, 1 Jul 2010, ik wrote: On Thu, Jul 1, 2010 at 10:33, Michael Van Canneyt < > >wrote: > > 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. >>> >>> >> 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 alltogether at once. >> >> > > 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. > Where is this generator ? I should remove it too.

‎The generator does not exists anymore, the example of svrclass_xmlrpc requires it under:
fpc/packages/fcl-net/examples

Show quoted text 9 lines
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.

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.

Show quoted text 8 lines
Michael. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Ido

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: That's why I work only in trunk. And as I understood it, Marco explicitly mentioned that…
Michael Van Canneyt wrote
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

You do you mean, I clearly see it listed in fpctomerge.txt (I just double checked).

Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Marco van de Voort: In our previous episode, Graeme Geldenhuys said: (or at all) We all know that, but we…
Marco van de Voort wrote 7 lines
> 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)

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.

Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/

Reply by email

Marco van de Voort
to Graeme Geldenhuys

In our previous episode, Graeme Geldenhuys said:

Show quoted text 5 lines
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.

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 :-)

Reply by email

Michael Van Canneyt
to ik: ‎The generator does not exists anymore, the example of svrclass_xmlrpc requires it…
ik wrote 47 lines
On Thu, Jul 1, 2010 at 10:54, Michael Van Canneyt wrote: > > > On Thu, 1 Jul 2010, ik wrote: > > On Thu, Jul 1, 2010 at 10:33, Michael Van Canneyt < >>> wrote: >> >> 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. >>>> >>>> >>> 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 alltogether at once. >>> >>> >> >> 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. >> > > Where is this generator ? I should remove it too. > ‎The generator does not exists anymore, the example of svrclass_xmlrpc requires it under: fpc/packages/fcl-net/examples

I'll remove that too.

Show quoted text 15 lines
> 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. > The names are misleading then :( WST is webdata am I correct ?

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.

Reply by email

Jonas Maebe
to Graeme Geldenhuys: You do you mean, I clearly see it listed in fpctomerge.txt (I just double checked). -…

Graeme Geldenhuys wrote on Thu, 01 Jul 2010:

Show quoted text 8 lines
On 1 July 2010 10:04, Michael Van Canneyt wrote: > > 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 You do you mean, I clearly see it listed in fpctomerge.txt (I just double checked).

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.

Reply by email

Marco van de Voort
to Jonas Maebe

In our previous episode, Jonas Maebe said:

Show quoted text 12 lines
> On 1 July 2010 10:04, Michael Van Canneyt wrote: >> >> 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 > > You do you mean, I clearly see it listed in fpctomerge.txt (I just > double checked). 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.

(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)

Reply by email