Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
On Thu, Jan 9, 2014 at 2:11 PM, Karsten Loesing karsten@torproject.orgwrote:
Hello coders,
is anyone here looking for a fun new project to hack on? Here's something you could do to help grow the Tor network:
We're planning to decommission the currently unmaintained Tor Weather which provides an email notification service to any users who want to monitor the status of a Tor node. And we'd like to replace it with a clean rewrite of this service.
https://weather.torproject.org/
(You're asking why we're not simply trying to find a new maintainer? That's also an option, but a clean rewrite that uses the Onionoo service would be much smaller and easier to maintain in the future. Read on to find out more.)
Here's what the rewritten Weather should do:
- Maintain a list of subscriptions, consisting of an email address, a
password, a relay identity fingerprint, how soon the user wants to be notified of problems, when it was last notified, etc.
- Allow users to create, read, update, and delete subscriptions via a
web interface. All these operations should have the usual security features like email address verification, password login, etc.
- Allow users to search for relays to subscribe for by relay IP address,
relay identity fingerprint, or relay nickname. This search can be done with help of Onionoo's search feature, or by simply adding a link to Atlas (https://atlas.torproject.org/) or Globe (https://globe.torproject.org/).
- Once per hour, download a list from Onionoo that contains relays that
have been running in the last week. Check if there are any relays that have been offline for long enough to notify a subscribed user. Send out emails.
- Once per day, download bandwidth histories of relays from Onionoo and
check whether a relay has been running long enough and fast enough that the operator should be offered a t-shirt. Send out emails, regardless of subscriptions, and ask if operators would want one.
As you can see, most of the work can be done with help of Onionoo. The parts that need to be written are a web and an email interface, a small database for subscriptions, and some glue code to talk to Onionoo.
(And if you still favor the variant where somebody maintains the current Weather, be aware that it needs to parse Tor descriptors and keep its own relay database to do searches, to check how long relays are offline, and to decide which relay operators should get a t-shirt.)
Here's some more information on the Onionoo service:
https://onionoo.torproject.org/
Happy to provide more information!
All the best, Karsten _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 1/9/14 11:30 AM, abhiram wrote:
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
Perfect!
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
Sure, here are two ideas:
- https://trac.torproject.org/projects/tor/ticket/9889#comment:2 has some URLs and pseudocode for using Onionoo's bandwidth documents to determine whether a relay operator should have a t-shirt.
- https://gitweb.torproject.org/compass.git/blob/HEAD:/compass.py fetches Onionoo's details documents, filters and groups relays, and generally provides the output on https://compass.torproject.org/.
If you have further questions or want me to review something, please let me know!
All the best, Karsten
On Thu, Jan 9, 2014 at 2:11 PM, Karsten Loesing karsten@torproject.orgwrote:
Hello coders,
is anyone here looking for a fun new project to hack on? Here's something you could do to help grow the Tor network:
We're planning to decommission the currently unmaintained Tor Weather which provides an email notification service to any users who want to monitor the status of a Tor node. And we'd like to replace it with a clean rewrite of this service.
https://weather.torproject.org/
(You're asking why we're not simply trying to find a new maintainer? That's also an option, but a clean rewrite that uses the Onionoo service would be much smaller and easier to maintain in the future. Read on to find out more.)
Here's what the rewritten Weather should do:
- Maintain a list of subscriptions, consisting of an email address, a
password, a relay identity fingerprint, how soon the user wants to be notified of problems, when it was last notified, etc.
- Allow users to create, read, update, and delete subscriptions via a
web interface. All these operations should have the usual security features like email address verification, password login, etc.
- Allow users to search for relays to subscribe for by relay IP address,
relay identity fingerprint, or relay nickname. This search can be done with help of Onionoo's search feature, or by simply adding a link to Atlas (https://atlas.torproject.org/) or Globe (https://globe.torproject.org/).
- Once per hour, download a list from Onionoo that contains relays that
have been running in the last week. Check if there are any relays that have been offline for long enough to notify a subscribed user. Send out emails.
- Once per day, download bandwidth histories of relays from Onionoo and
check whether a relay has been running long enough and fast enough that the operator should be offered a t-shirt. Send out emails, regardless of subscriptions, and ask if operators would want one.
As you can see, most of the work can be done with help of Onionoo. The parts that need to be written are a web and an email interface, a small database for subscriptions, and some glue code to talk to Onionoo.
(And if you still favor the variant where somebody maintains the current Weather, be aware that it needs to parse Tor descriptors and keep its own relay database to do searches, to check how long relays are offline, and to decide which relay operators should get a t-shirt.)
Here's some more information on the Onionoo service:
https://onionoo.torproject.org/
Happy to provide more information!
All the best, Karsten _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
https://trac.torproject.org/8264
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
Cheers! -Damian
On Thu, Jan 9, 2014 at 10:07 PM, Damian Johnson atagar@torproject.orgwrote:
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes
sense
to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 01/09/14 22:07, Damian Johnson wrote:
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
Sounds great, I took a cursory look at the Django application in the repo, I should be able to reuse many modules from there.
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
If I understood everything so far, I should look at ways to use Onionoo's restful service instead of the current approach which uses stem to grab hourly consensus updates of via the tor-network.
On 1/10/14 3:42 PM, Abhiram Chintangal wrote:
On 01/09/14 22:07, Damian Johnson wrote:
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
Sounds great, I took a cursory look at the Django application in the repo, I should be able to reuse many modules from there.
Great!
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
If I understood everything so far, I should look at ways to use Onionoo's restful service instead of the current approach which uses stem to grab hourly consensus updates of via the tor-network.
At least that's my suggestion, and I think it'll save us a lot of work in the long run. When I designed Onionoo, I had Weather in mind as possible client application. I think that Weather shouldn't have to implement its own Tor network status database. That's something that Onionoo already does, and it was painful enough to write. No reason to maintain quite similar code in Weather.
Obviously, there are also reasons against using Onionoo for the Weather rewrite. For example, fixing current Weather *might* take less effort than replacing its status database with an Onionoo client. And the new Weather will depend on the Onionoo service, rather than on a larger set of Tor directory authorities.
Please don't hesitate to add your own pros and cons to this list.
All the best, Karsten
Hi,
to make something this morning I made a fast and for sure not 100% correct design. But it describes roughly what I understood, the program should do and how. I made it with "Dia" open source OmniGraffle alternative. The link is on the wiki page and I hope we can use this as a first base to distribute the work packages and to discuss open topics. How to add properly files to the wiki? But the best is if you take a quick look.
Kind regards
Norbert
Am 12.01.2014 11:19, schrieb Karsten Loesing:
On 1/10/14 3:42 PM, Abhiram Chintangal wrote:
On 01/09/14 22:07, Damian Johnson wrote:
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
Sounds great, I took a cursory look at the Django application in the repo, I should be able to reuse many modules from there.
Great!
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
If I understood everything so far, I should look at ways to use Onionoo's restful service instead of the current approach which uses stem to grab hourly consensus updates of via the tor-network.
At least that's my suggestion, and I think it'll save us a lot of work in the long run. When I designed Onionoo, I had Weather in mind as possible client application. I think that Weather shouldn't have to implement its own Tor network status database. That's something that Onionoo already does, and it was painful enough to write. No reason to maintain quite similar code in Weather.
Obviously, there are also reasons against using Onionoo for the Weather rewrite. For example, fixing current Weather *might* take less effort than replacing its status database with an Onionoo client. And the new Weather will depend on the Onionoo service, rather than on a larger set of Tor directory authorities.
Please don't hesitate to add your own pros and cons to this list.
All the best, Karsten
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 1/12/14 1:44 PM, Nufuk wrote:
Hi,
to make something this morning I made a fast and for sure not 100% correct design. But it describes roughly what I understood, the program should do and how. I made it with "Dia" open source OmniGraffle alternative. The link is on the wiki page and I hope we can use this as a first base to distribute the work packages and to discuss open topics.
Cool! I added some feedback on the page. Thanks!
How to add properly files to the wiki?
You should be able to attach files to wiki pages using the buttons at the bottom of the page. Let me know if that doesn't work for you (because of permissions or something).
All the best, Karsten
But the best is if you take a quick look.
Kind regards
Norbert
Am 12.01.2014 11:19, schrieb Karsten Loesing:
On 1/10/14 3:42 PM, Abhiram Chintangal wrote:
On 01/09/14 22:07, Damian Johnson wrote:
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
Sounds great, I took a cursory look at the Django application in the repo, I should be able to reuse many modules from there.
Great!
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
If I understood everything so far, I should look at ways to use Onionoo's restful service instead of the current approach which uses stem to grab hourly consensus updates of via the tor-network.
At least that's my suggestion, and I think it'll save us a lot of work in the long run. When I designed Onionoo, I had Weather in mind as possible client application. I think that Weather shouldn't have to implement its own Tor network status database. That's something that Onionoo already does, and it was painful enough to write. No reason to maintain quite similar code in Weather.
Obviously, there are also reasons against using Onionoo for the Weather rewrite. For example, fixing current Weather *might* take less effort than replacing its status database with an Onionoo client. And the new Weather will depend on the Onionoo service, rather than on a larger set of Tor directory authorities.
Please don't hesitate to add your own pros and cons to this list.
All the best, Karsten
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, Jan 12, 2014 at 9:01 PM, Karsten Loesing karsten@torproject.org wrote:
On 1/12/14 1:44 PM, Nufuk wrote:
Hi,
to make something this morning I made a fast and for sure not 100% correct design. But it describes roughly what I understood, the program should do and how. I made it with "Dia" open source OmniGraffle alternative. The link is on the wiki page and I hope we can use this as a first base to distribute the work packages and to discuss open topics.
Cool! I added some feedback on the page. Thanks!
How to add properly files to the wiki?
You should be able to attach files to wiki pages using the buttons at the bottom of the page. Let me know if that doesn't work for you (because of permissions or something).
All the best, Karsten
But the best is if you take a quick look.
Kind regards
Norbert
The diagram was helpful, Norbert. I have aslo added a few questions in the projects wiki page can both of you take a look.
Thanks!
Am 12.01.2014 11:19, schrieb Karsten Loesing:
On 1/10/14 3:42 PM, Abhiram Chintangal wrote:
On 01/09/14 22:07, Damian Johnson wrote:
Hello Karsten,
It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too.
For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas?
thanks!
Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
Sounds great, I took a cursory look at the Django application in the repo, I should be able to reuse many modules from there.
Great!
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
If I understood everything so far, I should look at ways to use Onionoo's restful service instead of the current approach which uses stem to grab hourly consensus updates of via the tor-network.
At least that's my suggestion, and I think it'll save us a lot of work in the long run. When I designed Onionoo, I had Weather in mind as possible client application. I think that Weather shouldn't have to implement its own Tor network status database. That's something that Onionoo already does, and it was painful enough to write. No reason to maintain quite similar code in Weather.
Obviously, there are also reasons against using Onionoo for the Weather rewrite. For example, fixing current Weather *might* take less effort than replacing its status database with an Onionoo client. And the new Weather will depend on the Onionoo service, rather than on a larger set of Tor directory authorities.
Please don't hesitate to add your own pros and cons to this list.
All the best, Karsten
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi,
I made changes to the overall-design and added the files as an attachement to the site. I would like to implement the "daily" script and make a DB design diagramm. I would attach the DB design to the page when I finished it.
Could you please provide a quick brainstorm what the DB needs, so I won't forget anything.
regards
Norbert Kurz
Am 13.01.2014 17:25, schrieb Abhiram Chintangal:
On Sun, Jan 12, 2014 at 9:01 PM, Karsten Loesing karsten@torproject.org wrote:
On 1/12/14 1:44 PM, Nufuk wrote:
Hi,
to make something this morning I made a fast and for sure not 100% correct design. But it describes roughly what I understood, the program should do and how. I made it with "Dia" open source OmniGraffle alternative. The link is on the wiki page and I hope we can use this as a first base to distribute the work packages and to discuss open topics.
Cool! I added some feedback on the page. Thanks!
How to add properly files to the wiki?
You should be able to attach files to wiki pages using the buttons at the bottom of the page. Let me know if that doesn't work for you (because of permissions or something).
All the best, Karsten
But the best is if you take a quick look.
Kind regards
Norbert
The diagram was helpful, Norbert. I have aslo added a few questions in the projects wiki page can both of you take a look.
Thanks!
Am 12.01.2014 11:19, schrieb Karsten Loesing:
On 1/10/14 3:42 PM, Abhiram Chintangal wrote:
On 01/09/14 22:07, Damian Johnson wrote:
> Hello Karsten, > > It looks like a nice little project to work on. I reguarly check my > relay-status via Atlas, at the moment using the Onionoo service makes sense > to me too. > > For now the onionoo-glue-code, seems like a good place to start. Do you > have any other suggestions or ideas? > > thanks! Hi Abhiram, glad you want to tackle this! I'm not sure if it makes sense with the plan to rewrite Weather but six months back I submitted a patch to swap the present Weather from TorCtl to Stem...
Sounds great, I took a cursory look at the Django application in the repo, I should be able to reuse many modules from there.
Great!
Testing and merging that might be a fine way of getting acquainted to the present codebase and functionality.
If I understood everything so far, I should look at ways to use Onionoo's restful service instead of the current approach which uses stem to grab hourly consensus updates of via the tor-network.
At least that's my suggestion, and I think it'll save us a lot of work in the long run. When I designed Onionoo, I had Weather in mind as possible client application. I think that Weather shouldn't have to implement its own Tor network status database. That's something that Onionoo already does, and it was painful enough to write. No reason to maintain quite similar code in Weather.
Obviously, there are also reasons against using Onionoo for the Weather rewrite. For example, fixing current Weather *might* take less effort than replacing its status database with an Onionoo client. And the new Weather will depend on the Onionoo service, rather than on a larger set of Tor directory authorities.
Please don't hesitate to add your own pros and cons to this list.
All the best, Karsten
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 1/13/14 7:29 PM, Nufuk wrote:
Hi,
I made changes to the overall-design and added the files as an attachement to the site. I would like to implement the "daily" script and make a DB design diagramm. I would attach the DB design to the page when I finished it.
Could you please provide a quick brainstorm what the DB needs, so I won't forget anything.
Hi Norbert, hi Abhiram,
I'm trying to coordinate efforts a bit here:
- Norbert, how about you start writing the daily script as a stand-alone Python script that doesn't send out emails nor interact with a database yet? This first version of the script could simply print out which relay operators should be offered a t-shirt.
- Norbert, maybe we can re-use parts of the current Weather database. Should we try to do that first before designing a new database?
- Abhiram, it seems like you spent more time with the current Weather code base than Norbert or I. Would you want to find out how we'd integrate Norbert's daily script and later the hourly script into existing Weather and how these scripts would talk back to Weather to send out emails and talk to the database?
I suggested two tasks as possible next steps on the wiki. Maybe tweak them and add your initials if you want to grab them. (And feel free to add more task ideas, or in general make the wiki page better.)
All the best, Karsten
On Tue, Jan 14, 2014 at 3:22 PM, Karsten Loesing karsten@torproject.org wrote:
On 1/13/14 7:29 PM, Nufuk wrote:
Hi,
I made changes to the overall-design and added the files as an attachement to the site. I would like to implement the "daily" script and make a DB design diagramm. I would attach the DB design to the page when I finished it.
Could you please provide a quick brainstorm what the DB needs, so I won't forget anything.
Hi Norbert, hi Abhiram,
I'm trying to coordinate efforts a bit here:
- Norbert, how about you start writing the daily script as a stand-alone
Python script that doesn't send out emails nor interact with a database yet? This first version of the script could simply print out which relay operators should be offered a t-shirt.
- Norbert, maybe we can re-use parts of the current Weather database.
Should we try to do that first before designing a new database?
Norbert and Karsten, would a uml diagram of the existing models help?
- Abhiram, it seems like you spent more time with the current Weather
code base than Norbert or I. Would you want to find out how we'd integrate Norbert's daily script and later the hourly script into existing Weather and how these scripts would talk back to Weather to send out emails and talk to the database?
Sure, I am looking at some stem code right now, I will let you know once I get the hang of it.
About user management I looked at a few django thirdparty apps like django-userena and all. Do you have anything in mind ?
Thanks!
I suggested two tasks as possible next steps on the wiki. Maybe tweak them and add your initials if you want to grab them. (And feel free to add more task ideas, or in general make the wiki page better.)
All the best, Karsten
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 1/14/14 1:24 PM, Abhiram Chintangal wrote:
On Tue, Jan 14, 2014 at 3:22 PM, Karsten Loesing karsten@torproject.org wrote:
On 1/13/14 7:29 PM, Nufuk wrote:
Hi,
I made changes to the overall-design and added the files as an attachement to the site. I would like to implement the "daily" script and make a DB design diagramm. I would attach the DB design to the page when I finished it.
Could you please provide a quick brainstorm what the DB needs, so I won't forget anything.
Hi Norbert, hi Abhiram,
I'm trying to coordinate efforts a bit here:
- Norbert, how about you start writing the daily script as a stand-alone
Python script that doesn't send out emails nor interact with a database yet? This first version of the script could simply print out which relay operators should be offered a t-shirt.
- Norbert, maybe we can re-use parts of the current Weather database.
Should we try to do that first before designing a new database?
Norbert and Karsten, would a uml diagram of the existing models help?
Maybe? If there's an easy way to generate one, want to do that? (I put this task on the wiki and optimistically assigned it to you.)
- Abhiram, it seems like you spent more time with the current Weather
code base than Norbert or I. Would you want to find out how we'd integrate Norbert's daily script and later the hourly script into existing Weather and how these scripts would talk back to Weather to send out emails and talk to the database?
Sure, I am looking at some stem code right now, I will let you know once I get the hang of it.
Cool! Assigned this task to you in the wiki, so that nobody else grabs it for the moment.
(Also assigned the other task to Norbert for the same reason.)
About user management I looked at a few django thirdparty apps like django-userena and all. Do you have anything in mind ?
Is django-userena or one the other apps available as Debian package?
Maybe we should, at least for now, use what's already implemented in current Weather?
All the best, Karsten
Hello Norbert,
On 14/01/2014 15:22, Karsten Loesing wrote:
- Norbert, how about you start writing the daily script as a
stand-alone Python script that doesn't send out emails nor interact with a database yet? This first version of the script could simply print out which relay operators should be offered a t-shirt.
I was working a version of this script which checks if a relay deserves a tshirt. It was working fine before I started refactoring it. I never got around to finishing the refactor, and I may not be able to contribute to the weather rewrite.
The code might throw up an error in it's current state, but, I'm attaching it anyway with the hope that you find it useful.
Please use the code in whichever way you please, if it's helpful at all.
On 1/14/14 8:38 PM, Ravi Chandra Padmala wrote:
Hello Norbert,
On 14/01/2014 15:22, Karsten Loesing wrote:
- Norbert, how about you start writing the daily script as a stand-alone
Python script that doesn't send out emails nor interact with a database yet? This first version of the script could simply print out which relay operators should be offered a t-shirt.
I was working a version of this script which checks if a relay deserves a tshirt. It was working fine before I started refactoring it. I never got around to finishing the refactor, and I may not be able to contribute to the weather rewrite.
The code might throw up an error in it's current state, but, I'm attaching it anyway with the hope that you find it useful.
Please use the code in whichever way you please, if it's helpful at all.
Thanks, Ravi! I added your script to the wiki page.
All the best, Karsten
-
abhiram -
Abhiram Chintangal
-
Damian Johnson -
Karsten Loesing -
Nufuk -
Ravi Chandra Padmala