467,211 Members | 1,210 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,211 developers. It's quick & easy.

Web functions idea

I was musing recently about how one could, for example, set up a really
simple mailing subscription list. It occurred to me that a really simple
way to implement it would be to use xmlrpc.
So there could be a function
subscribe(emailAddress),
which would send an email for confirmation, and another function
confirm(emailAddress, password)
which would confirm the address ... and so on.

Now, the problem is that, if you use xmlrpc, it requires some kind of
fiddly software that the client would have to install. What you would
really want is some kind of web interface instead of xmlrpc - a kind of
"web driven xmlrpc" (that would eliminate the need of an actual xmlrpc
server).

The point of it being this: a developer would just write the functions
that he needed, a la xmlrpc, which would be "exposed" to this new module
(let's call it webrpc) - and webrpc would examine the function, work out
how many arguments it had, and display a form for the user to fill out.
From an application writer's point-of-view, it abstracts away the whole
web process, leaving him free to just concentrate on the underlying
function implementation.
Nov 29 '05 #1
  • viewed: 878
Share:
3 Replies
Mark Carter wrote:
I was musing recently about how one could, for example, set up a really
simple mailing subscription list. It occurred to me that a really simple
way to implement it would be to use xmlrpc.
So there could be a function
subscribe(emailAddress),
which would send an email for confirmation, and another function
confirm(emailAddress, password)
which would confirm the address ... and so on.

Now, the problem is that, if you use xmlrpc, it requires some kind of
fiddly software that the client would have to install. What you would
really want is some kind of web interface instead of xmlrpc - a kind of
"web driven xmlrpc" (that would eliminate the need of an actual xmlrpc
server).
Congratulations, you've just rediscovered REST !-)
The point of it being this: a developer would just write the functions
that he needed, a la xmlrpc, which would be "exposed" to this new module
(let's call it webrpc) - and webrpc would examine the function, work out
how many arguments it had, and display a form for the user to fill out.
From an application writer's point-of-view, it abstracts away the whole
web process,
I'm afraid doing web developpement without a minimal knowledge of "the
whole web process" is somewhat unrealistic.
leaving him free to just concentrate on the underlying
function implementation.


Turbogears is probably what you're looking for (if not quite what you
describe).

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Nov 29 '05 #2
bruno at modulix wrote:
Mark Carter wrote: Congratulations, you've just rediscovered REST !-)
Huzzah!
Turbogears is probably what you're looking for (if not quite what you
describe).


Thanks. It looks quite interesting.

Nov 29 '05 #3
The client software can be written in JavaScript that makes
xmlrpc calls to the server (AJAX). That way there is no
installation required.

But there are loads of free, debugged mailing list programs
out there that use email as the interface. You should take
a look there first.

-Larry Bates

Mark Carter wrote:
I was musing recently about how one could, for example, set up a really
simple mailing subscription list. It occurred to me that a really simple
way to implement it would be to use xmlrpc.
So there could be a function
subscribe(emailAddress),
which would send an email for confirmation, and another function
confirm(emailAddress, password)
which would confirm the address ... and so on.

Now, the problem is that, if you use xmlrpc, it requires some kind of
fiddly software that the client would have to install. What you would
really want is some kind of web interface instead of xmlrpc - a kind of
"web driven xmlrpc" (that would eliminate the need of an actual xmlrpc
server).

The point of it being this: a developer would just write the functions
that he needed, a la xmlrpc, which would be "exposed" to this new module
(let's call it webrpc) - and webrpc would examine the function, work out
how many arguments it had, and display a form for the user to fill out.
From an application writer's point-of-view, it abstracts away the whole
web process, leaving him free to just concentrate on the underlying
function implementation.

Nov 29 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by hokiegal99 | last post: by
99 posts views Thread by David MacQuigg | last post: by
7 posts views Thread by jolie.demiranda@gmail.com | last post: by
6 posts views Thread by harry | last post: by
44 posts views Thread by bahadir.balban@gmail.com | last post: by
110 posts views Thread by Gregory Pietsch | last post: by
20 posts views Thread by J de Boyne Pollard | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.