If there is a decision to keep a TPv2 in experimental state for a somewhat long term (1-2 years), who will be responsible for maintaining features equal with the current TP?
I don’t think its fair to ask contributors to write double the UI code. —Eric > On Apr 10, 2019, at 6:40 PM, Rawlin Peters <[email protected]> wrote: > > Yeah, I think this is just the nature of Javascript UI frameworks and > the pace at which they are advancing, but eventually we will have to > get off of AngularJS anyway since it will no longer be supported after > June 30, 2021: > https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c. > > So maybe it makes the most sense to try to get ahead of that and > implement any significant new self-service features in TPv2 rather > than trying to tack self-service features onto the existing TP. At > least it seems like Angular 2+ (currently at 7 now) has some better > staying power and clear upgrade paths. > > - Rawlin > > On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan > <[email protected]> wrote: >> >> They can be. There's no reason they can't. But the framework it's built on >> is on life support, TS > JS, fragile dependencies etc. etc. >> >> But the upshot is that I believe the effort to support self service would be >> just as much work either way, but done this way we eliminate/mitigate those >> problems at the same time. >> ________________________________________ >> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus >> (UK) Limited -OBO at Cisco) <[email protected]> >> Sent: Wednesday, April 10, 2019 3:55 PM >> To: [email protected] >> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service >> >> Why can’t the form wizards and other self-service features be built into the >> existing AngularJS Traffic Portal code? >> >> —Eric >> >> >>> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <[email protected]> wrote: >>> >>> I think I agree with Chris about just using the "experimental" folder as we >>> always have. Then it's pretty easy to look in there and see what's >>> "cooking": >>> >>> experimental >>> - traffic_router_golang >>> - traffic-portal-angular7 >>> - traffic_ops_ruby_on_rails (just kidding :) ) >>> >>> Now regarding TP and TPv2. At comcast, there are (or will be) 2 audiences >>> for TP: >>> >>> 1. Admin/ops type users >>> 2. self-service type users >>> >>> TP works well for #1 but not really for #2. The trick is to build a UI that >>> works well for both OR have 2 distinct UIs. As developers, we don't like >>> the idea of 2 UIs as that sounds like double the UI work when something >>> changes. >>> >>> So we could either: >>> >>> a. make TP (angularJS) more self-service friendly >>> b. create TPv2 (angular7) with self-service in mind (i.e. form wizards and >>> such) and focus on ds, user and tenant management and then slowly port the >>> rest of TP functionality into it >>> c. support 2 distinct UIs >>> >>> I think "b" makes sense and the effort can start (as many of our efforts >>> do) as "experimental" and if it gets legs maybe it does replace TP or maybe >>> it doesn't and it simply becomes a UI that you can use (or not use) to >>> solve ds/user/tenant management in a simple/self-service type way. >>> >>> Jeremy >>> >>> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <[email protected]> wrote: >>> >>>>> Are we seriously considering totally re-writing another component? >>>> >>>> Depends how you count it. One of the most important parts of the >>>> previous re-write (still in progress) is the "separation of powers" >>>> that makes things like this relatively non-destructive and able to be >>>> managed in parallel. I like experimental pokes into what the future >>>> might hold, like this one. I'm not totally sold, but the scope isn't >>>> crazy. It's mostly a UI on top of the existing API. >>>> >>>> Historically, experimental or alternate components have lived in the >>>> main branch, but the experimental folder. That lets them be part of >>>> the same process as the rest of the code, ensures code reviews as they >>>> progress, and the CI will keep everything in license compliance. >>>> >>>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan >>>> <[email protected]> wrote: >>>>> >>>>> Branching is fine with me, I doubt I have permission to create a branch >>>> myself, though. >>>>> >>>>> As an aside based on that: should `traffic_router_golang` also be moved >>>> to a branch? I think the branch idea is better than having an >>>> `experimental` directory. Or maybe that experiment is dead and should just >>>> be removed instead? The last change was 10 months ago. >>>>> ________________________________________ >>>>> From: Gray, Jonathan <[email protected]> >>>>> Sent: Wednesday, April 10, 2019 9:09 AM >>>>> To: [email protected] >>>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ >>>> Self-Service >>>>> >>>>> Instead of merging it into master, could we merge it to a feature branch >>>> like `experimental/TP.rewrite` if there is a desire for collaborative >>>> efforts. This would allow changes to flow in without adding more code to >>>> our normal review processes and polluting the changelog with WIP until it's >>>> done and ready to be merged. As an additional bonus it provides a more >>>> stable development for the new work since you'd be choosing when to pay the >>>> merge costs of ongoing master changes. >>>>> >>>>> Jonathan G >>>>> >>>>> >>>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <[email protected]> >>>> wrote: >>>>> >>>>> I guess that depends what you mean by "we". I personally think it's >>>> worthwhile, and I'll probably keep working on it until it reaches feature >>>> parity with the existing TP. >>>>> >>>>> I'm not saying development on the existing AngularJS-based TP should >>>> stop in the meantime, just that self-service be implemented separately in a >>>> more modern and flexible framework. Then - and only then - should we >>>> consider replacing the old TP with the new. Slowly, over time. The current >>>> TP was built for admins, so I don't think it'd actually be more work to >>>> implement a customer-facing interface this way than restructuring the >>>> existing TP to support it. >>>>> ________________________________________ >>>>> From: Hank Beatty <[email protected]> >>>>> Sent: Wednesday, April 10, 2019 8:38 AM >>>>> To: [email protected] >>>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ >>>> Self-Service >>>>> >>>>> Hello, >>>>> >>>>> Are we seriously considering totally re-writing another component? >>>>> >>>>> -Hank >>>>> >>>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote: >>>>>> Some of you may have heard, but about two and a half weeks ago I >>>> opened a Pull Request to add something to the `/experimental` directory. >>>> It's basically a re-implementation of Traffic Portal, which I think is >>>> beneficial not only because Traffic Portal wasn't designed with >>>> self-service in mind, but also because it cleans up a few issues on the >>>> development side. First of all, it uses the most recent LTS version of >>>> Angular, while the one on which Traffic Portal is currently based is now >>>> deprecated (this new version can also compile projects for Electron, which >>>> would make TP distributable as a standalone/mobile app). It also uses >>>> Typescript which compiles more cleanly to an overall smaller product, and >>>> is much easier to read, write and document. Remember the SCSS compiler >>>> issues (compass) we keep having? Angular 7 comes with a compiler at project >>>> init, so we never need that as an externally-provided dependency again. >>>> Finally, it already has unit testing and end-to-end testing working in four >>>> different JS engines. >>>>>> >>>>>> >>>>>> I'm currently looking for a reviewer ( >>>> https://github.com/apache/trafficcontrol/pull/3419) and you can read more >>>> about what's implemented there, but a short summary: >>>>>> >>>>>> >>>>>> * Login/authentication and API proxy >>>>>> * Delivery Service view with bandwidth charts >>>>>> * New Delivery Service creation targeted at self-service users >>>> with limited advanced editing options >>>>>> >>>>>> * User listing (read-only) >>>>>> >>>>>> * Preliminary HTTPS support (currently only listens on 'localhost') >>>>>> >>>>>> >>>>>> Plus, if I do say so myself, it all looks pretty snappy on every >>>> screen I could test. >>>>>> >>>>>> >>>>>> Feedback is also appreciated, especially concerning the "New >>>> Delivery Service" form. >>>>>> >>>>> >>>>> >>>> >>
