Thomas,
In lue of an email robot, what if you could submit data using curl?
I understand the you need, but I also understand how complex it could be two run to update mechanisms
On Fri, Sep 13, 2013 at 02:28:08PM +0200, Thomas Osterried wrote:
We need the bot. We can't live with a web frontend.
We need the bot. We can't live with a web frontend.
Is the dns bot that broken where there's a real need to "fix" it?
IMHO a single portal = single point of failure for a /8 subnet.
</$0.02>
It seems to me that the issue could be fixed with a JSON or SOAP API built into the portal website.
That would allow end-users to update information on the portal using scripts or whatever mechanism they liked. Also because the API is hooked into the portal's backend, there's no need to have a separate mechanism or script to sync everything up between the DNS server, portal, and the API, like is required with the email bot.
Also, because the API wouldn't need to be stateful, standard load balancing could allow for backup servers.
Just an idea,
Blaine, K1QV
On Fri, Sep 13, 2013 at 9:27 AM, kb9mwr@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Thomas,
In lue of an email robot, what if you could submit data using curl?
I understand the you need, but I also understand how complex it could be two run to update mechanisms
On Fri, Sep 13, 2013 at 02:28:08PM +0200, Thomas Osterried wrote:
We need the bot. We can't live with a web frontend.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
I had thought that an API into the backend would be a good idea, something standard like WSDL & SOAP would probably be the way to go.
Thoughts?
Chris
On 15 Sep 2013, at 05:06, Blaine Forbort b.forbort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ It seems to me that the issue could be fixed with a JSON or SOAP API built into the portal website.
That would allow end-users to update information on the portal using scripts or whatever mechanism they liked. Also because the API is hooked into the portal's backend, there's no need to have a separate mechanism or script to sync everything up between the DNS server, portal, and the API, like is required with the email bot.
Also, because the API wouldn't need to be stateful, standard load balancing could allow for backup servers.
Just an idea,
Blaine, K1QV
On Fri, Sep 13, 2013 at 9:27 AM, kb9mwr@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Thomas,
In lue of an email robot, what if you could submit data using curl?
I understand the you need, but I also understand how complex it could be two run to update mechanisms
On Fri, Sep 13, 2013 at 02:28:08PM +0200, Thomas Osterried wrote:
We need the bot. We can't live with a web frontend.
On Sep 15, 2013 12:44 AM, "Chris" chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ I had thought that an API into the backend would be a good idea,
something standard like WSDL & SOAP would probably be the way to go.
Thoughts?
Yes, please. I prefer RESTful APIs using json, rather than the xml based protocols you suggest.
Tom KD7LXL
Sent from my iPhone
On Sep 15, 2013, at 8:22 AM, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sep 15, 2013 12:44 AM, "Chris" chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ I had thought that an API into the backend would be a good idea,
something standard like WSDL & SOAP would probably be the way to go.
Thoughts?
Yes, please. I prefer RESTful APIs using json, rather than the xml based protocols you suggest.
Tom KD7LXL
[If my dog slaps my hand one more time while I'm writing an email I'll run away from home.]
SOAP and JSON both have their own advantages and disadvantages. I personally like SOAP because of its sophisticated error handling and the fact that it integrates into my applications so well. But, this would be a very simple API and shouldn't require all those features, so JSON might be the easier approach, should anyone volunteer to make this happen.
I also had another idea on how gateways could be entered and updated on the portal, a little more complicated on the server side but 'stupid simple' for the user. A system similar to E.164 used by telephone companies could be created that would allow users to update their info via a DDNS client. Here's an example:
1) I'm assigned the address range 44.4.36/29 2) I install a DDNS client on my gateway (i.e. ddclient) 3) In ddclient's config, i set my hostname to 44.4.36.0.29.ddns.ampr.org, and supply it with my portal username and password 4) after rebooting, ddclient automagically updates the portal (via this new system) with my machines external IP address, and continually checks to insure that the IP is updated should it change.
On the server side, this new server would need to pretend to be a DDNS server, but in actuality, would just parse those incoming updates into the encap file.
Something to think about anyway,
Blaine, K1QV
Sent from my iPhone
On Sep 15, 2013, at 8:22 AM, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sep 15, 2013 12:44 AM, "Chris" chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ I had thought that an API into the backend would be a good idea,
something standard like WSDL & SOAP would probably be the way to go.
Thoughts?
Yes, please. I prefer RESTful APIs using json, rather than the xml based protocols you suggest.
Tom KD7LXL
Entering data from the web portal into DNS is simple.
Having a script that does DDNS via a simple script to update the DNS is also easy.
Just need to know who has the time to do it.
Best Regards, Hugh G7UOD
H +44 7841 749345 + g7uod@onlineham.net -----Original Message----- From: 44net-bounces+hugh=teqsys.net@hamradio.ucsd.edu [mailto:44net-bounces+hugh=teqsys.net@hamradio.ucsd.edu] On Behalf Of Blaine Forbort Sent: 15 September 2013 17:42 To: AMPRNet working group Subject: Re: [44net] Reboot (DNS)
(Please trim inclusions from previous messages) _______________________________________________ [If my dog slaps my hand one more time while I'm writing an email I'll run away from home.]
SOAP and JSON both have their own advantages and disadvantages. I personally like SOAP because of its sophisticated error handling and the fact that it integrates into my applications so well. But, this would be a very simple API and shouldn't require all those features, so JSON might be the easier approach, should anyone volunteer to make this happen.
I also had another idea on how gateways could be entered and updated on the portal, a little more complicated on the server side but 'stupid simple' for the user. A system similar to E.164 used by telephone companies could be created that would allow users to update their info via a DDNS client. Here's an example:
1) I'm assigned the address range 44.4.36/29 2) I install a DDNS client on my gateway (i.e. ddclient) 3) In ddclient's config, i set my hostname to 44.4.36.0.29.ddns.ampr.org, and supply it with my portal username and password 4) after rebooting, ddclient automagically updates the portal (via this new system) with my machines external IP address, and continually checks to insure that the IP is updated should it change.
On the server side, this new server would need to pretend to be a DDNS server, but in actuality, would just parse those incoming updates into the encap file.
Something to think about anyway,
Blaine, K1QV
Sent from my iPhone
On Sep 15, 2013, at 8:22 AM, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sep 15, 2013 12:44 AM, "Chris" chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ I had thought that an API into the backend would be a good idea,
something standard like WSDL & SOAP would probably be the way to go.
Thoughts?
Yes, please. I prefer RESTful APIs using json, rather than the xml based protocols you suggest.
Tom KD7LXL -------------- next part -------------- An HTML attachment was scrubbed... URL: http://hamradio.ucsd.edu/mailman/private/44net/attachments/20130915/c 290d323/attachment.html _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Something like:
Perhaps?
On Sun, Sep 15, 2013 at 2:44 AM, Chris chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ I had thought that an API into the backend would be a good idea, something standard like WSDL & SOAP would probably be the way to go.
Thoughts?
Chris
On 15 Sep 2013, at 05:06, Blaine Forbort b.forbort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ It seems to me that the issue could be fixed with a JSON or SOAP API
built
into the portal website.
That would allow end-users to update information on the portal using scripts or whatever mechanism they liked. Also because the API is hooked into the portal's backend, there's no need to have a separate mechanism
or
script to sync everything up between the DNS server, portal, and the API, like is required with the email bot.
Also, because the API wouldn't need to be stateful, standard load
balancing
could allow for backup servers.
Just an idea,
Blaine, K1QV
On Fri, Sep 13, 2013 at 9:27 AM, kb9mwr@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Thomas,
In lue of an email robot, what if you could submit data using curl?
I understand the you need, but I also understand how complex it could be two run to update mechanisms
On Fri, Sep 13, 2013 at 02:28:08PM +0200, Thomas Osterried wrote:
We need the bot. We can't live with a web frontend.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
-
Blaine Forbort -
Brian Rogers -
Chris -
Hugh Golding -
kb9mwr＠gmail.com -
Neil Johnson -
Tom Hayward