Hi,
The breakdown looks good, but I think you should aim to keep the
implementation in Cassandra simple to start with and not underestimate how
much time it may take to implement both read/write and access control on
read/write. No need to change the plan or be too specific at this stage.
Best Regards
Ian
On 12 April 2013 23:24, Dishara Wijewardana ddwijeward...@gmail.com wrote:
Hi Ian,
I am in the process of writing the proposal. So as you mentioned earlier it
is better to split this in to 4 sub tasks and 2 before midterm and 2 after
mid term.
So in summary I would like to add the subtasks that I feel. Please add
anything I am missing or anything required to have.
Main tasks overview:
1. Implementing a CassandraResourceProvider to READ from Cassandra.
Implementation Details [1]
2. Test with one node Cassandra cluster end to end with the implementation
of #1.
3. Enhance CassandraResourceProvider to READ with access control (with
latest security related APIs).
4. Enhance CassandraResourceProvider(or may be a new interface for writing
i.e CassandraPopulator) to WRITE and WRITE with access control.
Here as I feel, #1 and #2 completion will more weight and relatively more
time consuming than #3 and #4 (I am not aware of the complexity of
incoperating the access control to READ/WRITE).
Appreciate your valuable feedback on this, whether this task breakdown is
appropriate or not suits to the GSoC time line or anything more to
add/remove and etc ?
[1] : Implementation Details:
- Write a CassanrdaResourceProviderUtil which is basically a cassendra
client which will facilitate all cassandra related operations required by
other modules (CassandraResourceProvider and CassandraResourceResolver).
- Implementation of CassandraResourceProvider
- Implementation of CassandraResourceResolver
- Implementation of CassandraResource
On Sun, Apr 7, 2013 at 3:27 PM, Ian Boston i...@tfd.co.uk wrote:
On 7 April 2013 14:07, Dishara Wijewardana ddwijeward...@gmail.com
wrote:
On Sun, Apr 7, 2013 at 3:00 AM, Ian Boston i...@tfd.co.uk wrote:
That sounds good.
If you havent already it will be important to become familiar with
OSGi
and
Sling itself.
Please dont do too much work before getting being accepted. I
cant guarantee that you will be accepted since there are lots of
Apache
projects, lots of submissions and a limited number of places given to
Apache.
Yes I agree with you. There are loads of projects from Apache each
year.
But if the proposal is solid where it's apparently attainable within
the
timeline and if community willing to mentor the project with high
priority,
I think there is a very good chance of getting accepted. But still
can't guarantee it 100%. I got what you meant ;-).
Good, we understand each other, and your analysis is correct.
Just incase it hasn't been obvious, I am very willing to mentor this
project, as are other members of the community for other projects.
Ian
Thanks for the feedback.
Have a great weekend.
Ian
On 7 April 2013 02:12, Dishara Wijewardana ddwijeward...@gmail.com
wrote:
Hi Ian
Than you for the quick response. I have started localhost Cassendra
and
written some codes through hector API to create columns and etc.
And
works
fine. I am still doing some more test codings to get familiar more
with
Cassendra these days so that I can reuse those codes and write an
appropriate CassendraResourceProviderUtil class .Meanwhile I will
prepare
the project proposal. Please let me know if you want something
more/else
to be done before hand that would be useful to this project.
On Sat, Apr 6, 2013 at 12:45 PM, Ian Boston i...@tfd.co.uk wrote:
Hi
Hector looks good.
Sling wont ship a Cassandra instance, for this project it will
uses a
Cassandra instance setup separately Last time I spun up
Cassandra
it
for
dev purposes it was just as easy as installing MySQL or
PostgreSQL,
so
I
think that fine.
+1.
If using Hector, I think it would be good to do everything in CQL
and
keep
it all very simple and transparent. Remember the aim of the
project
is
to
prove that the ResourceProvider API can support Cassandra as a
repository
store, and that API is complete and usable all the way through to
the
latest security related APIs that have just been developed. This
project
is
not an exercise in doing cool and complex things in Cassandra
with automated ORM mapping that binds the code forever to one
Cassandra
API.
Totally agree. So ideally in a users's perspective, when dealing
with
sling
layer, there should not be any difference between the resources in
/root/jackrabbit and /root/cassandra
