search

LabVIEW-DCAF / TagEditorCore

The collection of sample projects, libraries, class implementations, and APIs which make up the core of DCAF.
http://www.ni.com/dcaf
Apache License 2.0
8 stars 6 forks source link

Web tag viewer #342

Open pollockm opened 7 years ago

pollockm commented 7 years ago

We need a replacement for Tag Bus Web to allow for quick and easy monitoring of live tag status. Intended to be a simple read-only interface.

Propose: Use the identical approach used by the persistence request (store values in a local SQLite database). Suggest a different database file for values meant to be exposed to web (for security paranoia reasons), but generally the same implementation: a publish checkbox on the Tags editor page, a decimation factor for updates, and a decimated process that moves current value of tags in publish list to the publish DB.

From there, we just need a webpage that scans the DB table at some interval and prettily formats the results, which should be straightforward. Also permits users to put whatever pretty skin on top that they want with minimal fuss.

Beazurt commented 7 years ago

This feature definition looks great as well. A few questions though:

Why does this need to go into core? In general I think if a module is capable of doing something, we should build a module instead of putting the functionality into the engine so that things stay...modular. Are there requirements for this that can't be handled well by a new module?

Read-only is a great start and will be very valuable, but I would expect that requests for writing will follow shortly after. Is there anything in this approach that would prohibit adding write functionality later?

pollockm commented 7 years ago

It does not need to go in core. I defaulted to here because I haven't made a repo yet, and wanted to document my thoughts. We may need modifications to core or the engine to support the necessary infrastructure, especially if we want to permit value forcing.

Beazurt commented 7 years ago

Agreed. Support for forcing, without requiring duplicate tags and a tag select module, is going to be a key decision for the design.

If this supports forcing in the engine, why shouldn't we also support forcing through other mechanisms? Putting all of that different code inside the engine would make it bloated. I think to do forcing properly we would probably want to make a new plugin hook in the engine specifically for code that is allowed to break the current single-writer rule.

Given that would be a lot of work, unless there is a pressing need for it, it probably makes sense to plan on this not needing to support it.