With that said, I expect Gary is already working to address this concern
specifically:
> Looking at some of their names, they are generic sounding
> and it's not clear to me without digging in that they are
> part of coprocessors. Is it possible to move CP stuff into
> client.cp packages and the like? Or prefix with CoProc
> > or some way to keep this stuff separated?
which Stack mentioned as well. For sure we can make these kind of changes
before a commit.
Best regards,
- Andy
--- On Tue, 10/5/10, Andrew Purtell <[email protected]> wrote:
> From: Andrew Purtell <[email protected]>
> Subject: RE: dynamic RPC and coprocessor changes
> To: [email protected]
> Date: Tuesday, October 5, 2010, 7:38 PM
> We have been working on this for a
> while. It represents a significant investment. I see no
> reason why this work should be viewed as second class
> compared with some of the other work that has already gone
> in for 0.90. The patches have been up on reviewboard for
> over two weeks now, ample time for review.
>
>
> - Andy
>
>
> > From: Jonathan Gray <[email protected]>
> > Subject: RE: dynamic RPC and coprocessor changes
> > To: "[email protected]"
> <[email protected]>,
> "[email protected]"
> <[email protected]>
> > Date: Tuesday, October 5, 2010, 7:30 PM
> > Committing this stuff onto trunk the
> > day before a feature freeze and as we move towards
> stability
> > gives me a little bit of the fear.
> >
> > I completely understand that it's been worked on for
> quite
> > some time and think this stuff is awesome. But I
> still
> > wish I had more time to give it further review and to
> > actually take this stuff for a test spin. Right now
> > that's just not possible with all the work to be done
> > stabilizing and testing trunk (and I think time is
> best
> > spent right now stabilizing the master/rs versus new
> > features).
> >
> > Personally, I have a bunch of fairly sweeping
> compaction,
> > flush, and split changes that have been partially
> reviewed
> > but I haven't had the time to push them over the
> finish
> > line. I hope to get them in immediately after an
> 0.90
> > branch is cut and trunk becomes 0.92. This should
> be
> > rather soon. I'd like to see 0.92 get released in
> > short order after 0.90 as there are lots of changes
> that
> > just have not made it into 0.90 yet. So even if we
> > waited to commit, we could work hard towards the next
> major
> > release (I don't think there are any major rewrites
> > planned) :)
> >
> > With this kind of big change and addition of new APIs,
> my
> > preference would be to have it committed early in a
> trunk
> > cycle (versus immediately before a release is cut).
> > That way, we can play with it ourselves, see how it
> works,
> > try out some of our own ideas for usage of CPs, etc...
> In
> > doing that, I would expect there would be suggestions
> for
> > changes in the API, additions to the API, naming
> changes to
> > be more clear from a non-implementer POV, etc...
> >
> > By putting it in immediately before a release, the
> original
> > API can't be broken, class names can't be changed, all
> would
> > need to be deprecated, etc...
> >
> > The other issue I have with the current CP code that I
> have
> > read is the number of new classes introduced into
> existing
> > core packages (especially clent). Looking at some
> of
> > their names, they are generic sounding and it's not
> clear to
> > me without digging in that they are part of
> > coprocessors. Is it possible to move CP stuff into
> > client.cp packages and the like? Or prefix with
> CoProc
> > or some way to keep this stuff separated?
> >
> > I apologize for dropping this on you now and if no one
> else
> > feels the same, I am not going to spoil the party.
> >
> > But is it critical that this gets into 0.90 and into
> a
> > release now? Could we wait for 0.92 and get this
> > committed in a couple weeks and allowed to mature a
> bit on
> > trunk before it's released?
> >
> > JG
> >
> > > -----Original Message-----
> > > From: Andrew Purtell [mailto:[email protected]]
> > > Sent: Tuesday, October 05, 2010 7:14 PM
> > > To: [email protected]
> > > Subject: dynamic RPC and coprocessor changes
> > >
> > > We've been nursing dynamic RPC and coprocessor
> changes
> > for a couple of
> > > weeks now and don't see any failures beyond what
> are
> > already on trunk
> > > with them applied.
> > >
> > > I was going to apply them tonight but will wait
> until
> > tomorrow given
> > > that trunk is already disrupted a little.
> > >
> > > Best regards,
> > >
> > > - Andy
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
