Since the Cookie Jar functionality is new to 2.0 and 2.0 is not yet
released, why don't we just remove the `ResumeSession` method all together
and eliminate the dependency?  Otherwise we are deprecating something that
we never formally released.

On Tue, Apr 4, 2017 at 2:30 PM, Robert Butts <robert.o.bu...@gmail.com>
wrote:

> Regarding `TC-119: traffic_ops/client dependency license issue`:
>
> It looks like the persistent cookie jar is only needed by Traffic Ops
> Client `ResumeSession(toURL string, insecure bool) (*Session, error)`.
> Nothing in Traffic Control uses `ResumeSession`, and I doubt anyone else is
> using it. Because it returns an error, and persisted cookies have
> lifetimes, any current users already must handle errors from persisted
> cookies being expired. Thus, we can change it to always return an error
> with only degraded performance (and not much, login is cheap), without loss
> of functionality.
>
> To fix TC-119, I propose we document `ResumeSession` as deprecated, and
> change it to always return an error, which lets us remove the dependency,
> without the development cost of writing our own persistent cookie store
> that no one is using.
>
> Any objections?
>
>
> On Tue, Apr 4, 2017 at 1:35 PM, Jeremy Mitchell <mitchell...@gmail.com>
> wrote:
>
> > These all got fixed and backported to 2.0:
> >
> > TC-203: Mojo doesn’t set cachable headers on public files”
> > TC-190: TTL type mismatch in CrConfig
> > TC-189: ssl_multicert.config too slow
> >
> > So Jan and Dave just need to close the issues.
> >
> > On Tue, Apr 4, 2017 at 12:22 PM, Jeffrey Martin <martin.jef...@gmail.com
> >
> > wrote:
> >
> > > Hi Eric,
> > > I was going to address the immediate Postinstall issues TC-185. I am
> way
> > > late on this. I created a fork yesterday, need to run a couple of tests
> > and
> > > then I can push to this fork.
> > > Jeff Martin
> > >
> > >
> > > On Tue, Apr 4, 2017 at 1:59 PM, Eric Friedrich (efriedri) <
> > > efrie...@cisco.com> wrote:
> > >
> > > > We have some release blockers for 2.0. Specifically:
> > > >
> > > > TC-119: traffic_ops/client dependency license issue
> > > >     We cannot ship with Category-X LGPL software, so I’m waiting for
> > this
> > > > to be resolved before cutting a release branch
> > > >  "TC-185 post install doesn’t run due to missing perl module”
> > > >     We shouldn’t ship a release in which the install process is
> broken
> > in
> > > > this way.
> > > >    *There’s no assignee yet for this, any volunteers?*
> > > >
> > > > I think if we can get those two taken care of we can cut an RC0 later
> > > this
> > > > week.
> > > >
> > > > Major bugs we will ship with (unless someone objects):
> > > >     TC-203: Mojo doesn’t set cachable headers on public files”
> > > >     TC-190: TTL type mismatch in CrConfig
> > > >     TC-189: ssl_multicert.config too slow
> > > >
> > > > —Eric
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > On Apr 4, 2017, at 1:13 PM, Dave Neuman <neu...@apache.org> wrote:
> > > > >
> > > > > Good question.  I would also like to see us try to get some release
> > > > > candidates out for 2.0.  I am pretty sure the actual install and
> > > > > postinstall need work.  There are also a couple of issue that are
> > still
> > > > > assigned to 2.0 and unresolved:
> > > > > https://issues.apache.org/jira/browse/TC/fixforversion/
> > > > 12338562/?selectedTab=com.atlassian.jira.jira-projects-
> > > > plugin:version-summary-panel
> > > > > .
> > > > >
> > > > > On Tue, Apr 4, 2017 at 11:05 AM, Jan van Doorn <j...@knutsel.com>
> > > wrote:
> > > > >
> > > > >> When are we planning to release 2.0? We at Comcast are running
> what
> > we
> > > > >> call 2.0…. So we are +1, I am pretty sure.
> > > > >>
> > > > >> Eric: are you waiting for something? Which cats need herding?
> > > > >>
> > > > >> Rgds,
> > > > >> JvD
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Reply via email to