On 7/6/2011 04:22, ik wrote:
Hello,
One of the thing that I find really missing in fpWeb is the ability to
have support for REST.
That is, to place different callbacks to GET, POST, UPDATE, DELETE,
HEAD and PUT.
Let's say that I create a support for the following PATH_INFO:
I started som
On Tue, 7 Jun 2011, ik wrote:
On Tue, Jun 7, 2011 at 20:54, Michael Van Canneyt
wrote:
On Tue, 7 Jun 2011, ik wrote:
As you know REST is an architecture, not just a set of classes
or methods.
REST doesn't even require HTTP. So calling a webserver c
On Tue, Jun 7, 2011 at 20:54, Michael Van Canneyt wrote:
>
>
> On Tue, 7 Jun 2011, ik wrote:
>
> As you know REST is an architecture, not just a set of classes or
>> methods.
>> REST doesn't even require HTTP. So calling a webserver class
>> RESTsomething
>> because onGet, onPut, e
On Tue, 7 Jun 2011, ik wrote:
As you know REST is an architecture, not just a set of classes or methods.
REST doesn't even require HTTP. So calling a webserver class RESTsomething
because onGet, onPut, etc. are exposed does not have any added value.
>I agree. This was why I
On Tue, Jun 7, 2011 at 17:49, wrote:
>
>
> On Tue, 7 Jun 2011, Ludo Brands wrote:
>
> Ok, that is simply an alternative to the current
>>> TFPWebDataModule which does
>>> not rely on part of the URL to determine the CRUD action, but
>>> uses the URL
>>> just to determine the resource, and the HT
Sorry, wrong link. Should be: http://sourceforge.net/projects/scitepp
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Userfriendly-editor-tp4459764p4462133.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
__
http://sourceforge.net/projects/scite++ SciTE++ for sure :) *my
modification*
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Userfriendly-editor-tp4459764p4462115.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
On Tue, 7 Jun 2011, Ludo Brands wrote:
Ok, that is simply an alternative to the current
TFPWebDataModule which does
not rely on part of the URL to determine the CRUD action, but
uses the URL
just to determine the resource, and the HTTP method to see
which CRUD action
needs to be performed.
Th
On Tue, 7 Jun 2011, reynolight wrote:
Am 06.06.2011 22:02, schrieb Rainer Stratmann:
http://www.geany.org/
Screenshots:
http://www.geany.org/uploads/Gallery/geany_main.png
http://www.geany.org/uploads/Gallery/geany_build.png
http://www.geany.org/uploads/Gallery/geany_plugins.png
__
> Ok, that is simply an alternative to the current
> TFPWebDataModule which does
> not rely on part of the URL to determine the CRUD action, but
> uses the URL
> just to determine the resource, and the HTTP method to see
> which CRUD action
> needs to be performed.
>
> That's easily done. It
Am 06.06.2011 22:02, schrieb Rainer Stratmann:
> http://www.geany.org/
> Screenshots:
> http://www.geany.org/uploads/Gallery/geany_main.png
> http://www.geany.org/uploads/Gallery/geany_build.png
>
> http://www.geany.org/uploads/Gallery/geany_plugins.png
> ___
On Tue, 7 Jun 2011, Ludo Brands wrote:
TCP is the transport layer, HTTP the application layer. Don't know what a
REST *transport layer* is, but i can guess what your question is about.
Well, I consider HTTP part of the the transport layer. The messages could be
transported over SMTP, after a
TCP is the transport layer, HTTP the application layer. Don't know what a
REST *transport layer* is, but i can guess what your question is about.
As you know REST is an architecture, not just a set of classes or methods.
REST doesn't even require HTTP. So calling a webserver class RESTsomething
be
On Tue, 7 Jun 2011, Ludo Brands wrote:
Please don't call it RESTsomething. REST involves much more than exposing
http methods. Just to avoid that in the future somebody complains about
missing REST features. Remember, a little while ago whe had somebody
complaining about URIParser not supporti
I don't care, as long it doesn't suggest features that aren't there. fpWeb2?
fpikWeb? fpEasyWeb? fpWeb+? fpWebExposingHTTPMethods?
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de ik
Envoyé : mardi 7 juin 2011
On Tue, Jun 7, 2011 at 12:45, Ludo Brands wrote:
> Please don't call it RESTsomething. REST involves much more than exposing
> http methods. Just to avoid that in the future somebody complains
> about missing REST features. Remember, a little while ago whe had somebody
> complaining about URIPar
Please don't call it RESTsomething. REST involves much more than exposing
http methods. Just to avoid that in the future somebody complains about
missing REST features. Remember, a little while ago whe had somebody
complaining about URIParser not supporting sip uri's ;)
-Message d'origine
On Tue, Jun 7, 2011 at 10:41, wrote:
>
>
> On Tue, 7 Jun 2011, ik wrote:
>
> Hello,
>>
>> One of the thing that I find really missing in fpWeb is the ability to
>> have
>> support for REST.
>>
>> That is, to place different callbacks to GET, POST, UPDATE, DELETE, HEAD
>> and
>> PUT.
>>
>
> Why d
On Tue, 7 Jun 2011, ik wrote:
Hello,
One of the thing that I find really missing in fpWeb is the ability to have
support for REST.
That is, to place different callbacks to GET, POST, UPDATE, DELETE, HEAD and
PUT.
Why do you think this is missing ? fpWeb does not really care about the metho
In our previous episode, Mattias Gaertner said:
> > '{print $8}'".
>
> Thanks, I knew that.
> I prefer a more direct way - for example via a sysctl.
Not yet, but I'll have a look.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://list
In our previous episode, Mattias Gaertner said:
> I need to check under BSD if a PID is running and what name it has.
> Is there already a function for that?
No. Note that /proc can be turned off on BSD, and often is so on servers, so
relying on is not that safe anyway.
___
Hello,
One of the thing that I find really missing in fpWeb is the ability to have
support for REST.
That is, to place different callbacks to GET, POST, UPDATE, DELETE, HEAD and
PUT.
Let's say that I create a support for the following PATH_INFO:
/records/
The class should have support imho to
22 matches
Mail list logo
