New XML sequencer project
by Randall Hauch
The XML sequencer has been moved out of the dna-graph project into a
new "dna-sequencer-xml" subproject (under 'extensions'). Please be
aware of this in case you need to add it into your IDE workspace.
Best regards,
Randall
17 years, 10 months
New JBoss DNA contributor: Sergiy Litsenko
by Randall Hauch
Please welcome Sergiy Litsenko as a new committer on the JBoss DNA
project. Sergiy is a new contributor to the JBoss family, but has
worked with JCR in a web application. He has experience with a
variety of technologies. He's interested in working in a number of
different areas in DNA, including connectors, REST access, and view
technologies. Oh, and his JBoss user ID is "lisbor".
Welcome to the team, Sergiy!
Best regards,
Randall Hauch
17 years, 10 months
JBoss DNA 0.3 planning
by Randall Hauch
Ready to shift your focus to 0.3? I hope so, because there's still a
lot to do.
I've mentioned before that we'd like to have a short development cycle
for the 0.3 release - hopefully around 3-4 weeks from now (if not
sooner). The main driver for this is that we know the connector
commands need to be improved, and there it'd be better to do it sooner
than later. We also want to add a graph API to hide those commands.
So, rather than start out with a huge list of issues where most would
not get tackled in a short release, I thought it'd be better to start
with a clean list and pull into 0.3 those issues we choose to work
on. And I did this last week. I created a 0.4 bucket and moved all
the issues that were in 0.3 and moved them into a new 0.4 release
bucket. I then went through the issues, and pulled back into 0.3
those issues that I know we wanted to work on. But now it's your turn.
Please review this 0.3 list and help make it what you want it to be.
There are currently several unassigned issues, ready for you if you're
looking for something to work on. Or, if there's an issue that you
want to work and that is not currently schedule for 0.3, go ahead and
move it to 0.3. In fact, Serge wanted to work on the SVN connector,
so https://jira.jboss.org/jira/browse/DNA-36 is now scheduled for 0.3.
And as always, if you have comments or questions, feel free to discuss
them here or on the issues.
Best regards,
Randall
17 years, 10 months
Proposed changes to the repository connector commands
by Randall Hauch
There are several known issues with the initial 0.2 design of the
commands used in the repository connector framework. These are
documented in https://jira.jboss.org/jira/browse/DNA-213. I've just
attached to that defect a patch (for the "dna-graph" project) that
adds a new package with a new design for these command classes (now
called "requests"). Hopefully this design gets us closer to
addressing the known issues.
I'm looking for any and all feedback. (Serge, you said you'd take a
look. :-)
Just in case you're not familiar with the commands, basically this is
the way the connectors work: a connector client (e.g., the JCR
implementation) creates a command for each request they want to have
processed by a connector. Multiple requests can be sent via a single
call to the connector, so it's possible, for example, to create a
graph of nodes all in one bulk call.
We can do some interesting things with the commands/requests. First,
we can batch them together (as I mentioned), or accumulated for
delayed execution (e.g., when a transaction is committed). Second, we
could preprocess them, if we want to enforce certain orders or if we
want to optimize a bunch of commands. Third, they can be serialized,
which will help with fault tolerance.
A fourth benefit is that it gives us some flexibility for future
changes. For example, we could introduce new commands without
requiring that connectors "understand" them (if the new commands could
be executed by default using other commands). This is where the
CommandExecutor comes it ... it's an abstract class that defines
methods for executing each type of command, and each connector
"implements its behavior" by implementing an executor. Some of the
core "execute" methods are abstract, meaning the connector is required
to implement them. Other methods are optional. For example,
executing a command to delete a set of children of a node can be
implemented in the abstract class by creating a "DeleteBranchCommand"
for each child. If a connector can implement this more efficiently,
then it should probably override the default method. However, it
wouldn't have to, and as long it implemented the core execute methods,
it would still work.
Now, we really don't want the commands to be exposed to clients, which
is why we want to create a little API on top of the commands - this is
what https://jira.jboss.org/jira/browse/DNA-215 is all about. Once we
have this, the JCR implementation, sequencers, etc. could use this
instead. Under the covers, the API would be creating commands and
sending them to the connector (when needed).
Okay, back to the issues. We found out late in 0.2 that the commands
didn't do everything we needed them to do, and if we're going to fix
them, we need to do it quickly. This is one of the reasons why we
want 0.3 to be short - we want to get these changes out the door so
that people can start writing connectors. Thus, https://jira.jboss.org/jira/browse/DNA-213
and https://jira.jboss.org/jira/browse/DNA-215 are two of the
biggest and most critical issues for 0.3. (The other blocker issue is https://jira.jboss.org/jira/browse/DNA-217
, which has to do with cancellation.)
Right now, I want to get the core commands/requests done and done
correctly. We'll add others in the future - for example some for
searching (e.g., via SQL, SPARQL, etc.).
Please speak up if you have any questions or comments or suggestions!
Best regards,
Randall
17 years, 11 months
