I have not done anything new with WeeRT for quite a while. Most of my
efforts have been in simplifying the back-end. The front-end has not
changed in a year.

The front-end is also where I'm weakest, so it could definitely use some
help!

Not wedded to Angular 1 at all. The only thing I feel strongly about is
that the client should use SVG, and not canvas. The reason is that
annotating individual data points, as well as a smooth real-time display,
require SVG. Using SVG strongly suggests using D3.

Matthew has experimented with various D3 libraries
<https://github.com/matthewwall/plotting>. I think it's fair to say that
his conclusion is that they have certainly gotten better, and may even be
ready for prime-time. Although he found that most of them are slow, that's
mostly because he was using very large data sets. Perhaps Matthew can chime
in with his thoughts. If we go this route, then a requirement would be that
the library be under active development.

-tk


On Sat, Jan 7, 2017 at 9:11 AM, Chris Matteri <[email protected]>
wrote:

> Hi,
>
> What's the status of WeeRT? I would be interested in helping with it if
> you'd like. I could focus on morphing WXPlot into a component that could be
> used in the WeeRT client, but I'm happy to work on the backend or some
> other part of the frontend as well.
>
> How set are you on using Angular in the client? React seems to be
> surpassing it in popularity and with the release of Angular 2 (which is
> different enough from Angular 1 that people are calling it a new framework
> rather than an upgrade), Angular 1 is on track to become less relevant. If
> you're interested in React, I would be happy to help port the client to it.
>
> -Chris
>
> On Sat, Sep 10, 2016 at 3:11 PM, Thomas Keffer <[email protected]> wrote:
>
>>
>>
>> On Sat, Sep 10, 2016 at 11:06 AM, Chris Matteri <[email protected]>
>> wrote:
>>
>>>
>>> I would certainly be open to real-time updates, but that would probably
>>> work better with WeeRT as a backend, because there's no way to get the data
>>> between the last archive record and the time the webpage loads (that I know
>>> of).
>>>
>>>
>> ​WeeRT actually stores the LOOP packets in a MongoDB collection. The
>> collection can be a "capped collection," so it doesn't grow without bounds.
>> It's job is just to store the most recent data at high-resolution for
>> zooming.
>>
>> On startup, the client queries the WeeRT server for LOOP packets for the
>> last few hours.  New data comes in via a push connection from a websocket.
>> The client just appends it to data it already has.​
>>
>>
>>> My immediate plans are to clean up and comment the code and to add rain
>>> plots, but it would be nice to integrate it with WeeRT at some point.
>>>
>>>
>> ​I vote for this! :-)
>>
>> Right now, the API supports queries for LOOP packets at arbitrary
>> aggregations. But, that's only going to work for plotting the last few days
>> --- the database can't possibly store years worth of LOOP packets. So, the
>> intention is to run regular map-reduce sessions to aggregate the data into
>> something courser, probably about 5 minute intervals. This will then get
>> map-reduced to even courser daily data. Hopefully, this will facilitate
>> zooms from seconds resolution out to years.
>>
>> -tk​
>>
>>
>
>

Reply via email to