accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2589) Create new client API
Date Wed, 03 Dec 2014 04:56:12 GMT


Josh Elser commented on ACCUMULO-2589:

bq. wired to the implementation in the core jar using java's ServiceLoader

Interesting, I haven't looked at ServiceLoader at all before. A brief read-up seems like it
makes a lot of sense for the future.

bq. figure out how we want to do exception handling in the new API (there have been many suggestions)

We should start this talk (again) sooner rather than later :). It'll be a doozie. 

bq. I'm also trying to find a sensible serialization practice that we can use on our "dumb"
objects that doesn't depend on Hadoop libraries, but satisfies our serialization needs (in
particular, credentials).

This is interesting sounding, but I'm not 100% sure what you mean here. The thrift classes
we have now? Do you have a separate issue for this already that we can start a discussion

bq. As for uploading as a feature branch, I didn't want to spam the mailing lists with repeated
rebase-ing, at least until it's a bit more stable and ready to contribute back to the project.
I can collaborate on GitHub, though. I definitely don't want to discourage help from others...
but I'd rather collaborate on GitHub until it's at least a little bit more stable and ready
to contribute.

My biggest regret in working on replication is how long I let it live in its own branch. This
was the easy/lazy decision to make, but I'm convinced it's split me and the feature off from
the rest of the community. If it lives in a bubble too long, it just becomes infeasible to
bring the other devs up to speed. For replication, this was more "ok" (not saying it was acceptable)
because it was an optional feature, but since the client API is of such importance, I would
encourage you to start bringing things up for review.

Assuming you have your own schedule for things you're working on, could you pull some code
into a feature branch in Apache for things you have already worked out? For example, take
the ServiceLoader code (or just look at the changes with a focus on the ServiceLoader): we
can isolate the changes you've made so far for that, you can get some feedback on it, and
then it would be one step closer to making it into master. Even if it changes again later
(as pieces likely will), that's not the end of the world -- more than just you can help evolve
the new implementation.Thoughts?

> Create new client API
> ---------------------
>                 Key: ACCUMULO-2589
>                 URL:
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: client
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>            Priority: Blocker
>             Fix For: 2.0.0
>          Time Spent: 10m
>  Remaining Estimate: 0h
> There are many issues with the current client API, and we've had a lot of lessons learned
that could be incorporated into a new one.
> Some of the issues this would address:
> * questions like "What is considered 'Public API'?"
> * automated testing for incompatible API changes
> * provide better support for alternative implementations of pluggable features
> * distinguish between compile-time dependencies and runtime dependencies
> * consistent exception handling
> * consistent/symmetric getters/setters
> * well-defined resource lifecycles
> * better resource management
> * simpler entry point to communicate with Accumulo
> * better support for client-side configuration management
> * logical layout of first class Accumulo objects in the API (Table, User, Scan, Connection)
> Some of these goal may evolve during the development of this feature, and many previously
identified issues can be moved to sub-tasks of this one. This ticket is intended to cover
the overall feature, but the details will be handled in sub-tasks.

This message was sent by Atlassian JIRA

View raw message