I concur with Rob. Experimental means "no promises, no demands". We need an exit plan for AngularJS and a contributor is offering an idea. I'm not 100% convinced, but I don't need to be. If someone has a better plan and some effort to put behind it, I'm all ears. Personally, I'm quite intrigued by the idea of a framework that could produce a mobile app suitable for origin owners to use in monitoring their stuff.
In the meantime, put it in experimental. That way, people can see what it has, use it if they find it useful, contribute to it if they find it lacking, and keep it "with" the rest of the code. Nobody has to maintain it, but if it turns out to be useful for people, they will. If it's sufficiently useful for everyone at some point, promote it and promise to maintain it. > traffic_ops_ruby_on_rails Your trolling game is very strong. :D On Thu, Apr 11, 2019 at 10:33 AM Robert Butts <[email protected]> wrote: > > +1 on putting it in /experimental. > > IMO no one should be required to be responsible for experimental. I think > we should be liberal about putting experimental things in the repo, under > /experimental, which aren't necessarily complete or well-maintained. So > people other than the author can see them, try them out, vote on whether > they're useful, etc. > > If at some point it becomes clear something in /experimental won't ever see > production, we just remove it. No big deal. > > > On Thu, Apr 11, 2019 at 10:08 AM Jeremy Mitchell <[email protected]> > wrote: > > > If Brennan focuses TPv2 on the self-service things (delivery service, user > > and tenant management), I think it would be his responsibility to ensure > > that any new functionality added to TPv1 regarding those 3 things is also > > added to his experimental TPv2. And once he starts adding other > > functionality (cache group, server management, etc), his scope will > > increase of the things he needs to keep an eye on. Then once TPv2 achieves > > critical mass, we'll have to officially deprecate TPv1 and only add new > > functionality to TPv2. So I don't see any double UI coding. At the rate we > > are turning out TC releases, maybe TPv2 is ready for 4.x :) (or at least > > the ds, user, tenant part) > > > > Jeremy > > > > On Thu, Apr 11, 2019 at 6:24 AM Eric Friedrich -X (efriedri - TRITON UK > > BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > > <[email protected]> wrote: > > > > > 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. > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>> > > > >> > > > > > > > >
