On 06/02/13 19:09, Stephen Allen wrote:
On Wed, Feb 6, 2013 at 12:40 PM, Andy Seaborne <[email protected]> wrote:
(tried to send and earlier version of this - also I put in some changes
then, on reflection, didn't like them and already reversed these changes)
UpdateEngine.getUpdateSink
I'm confused here - is it a getter or a creator?
The comments that were in UpdateEngineMain and the impl creates on each
call.
I've made it a getter-style on fixed UpdateSink for the single SPARQL Update
request.
I guess it should probably be a getter as you have changed it. I'm
not too clear on it myself.
I've just done the same to UpdateEngineNonStreaming -- my use case is a
single UpdateProcessorStreaming that is passed between software elements
that accumulates Updates from different places. Each calls
getUpdateSink to get the sink - so it had better be the same one.
Was going to ask why you made those changes, but then saw you reverted them :)
And I thought I'd sorted out the interfaces quite nicely until,
afterwards, I realised I hadn't at all. :-( Too much DNS wrestling
causing a distraction.
I've also been thinking about the 2.10.0 release. What parts do you
think I need to document more? The big change for users is the
removal of the initial binding capability. For implementers it is the
change to UpdateEngine/UpdateEngineFactory, but I think it should be
fairly straightforward if they look at UpdateEngineMain or
UpdateEngineNonStreaming.
IMO, a paragraph to give information on the new feature of streaming
updates, then an overview to say that engine implementers need to be
aware so that they don't first encounter this by compile errors or
runtime errors, then have to look in the code. Entries in ARQ release
notes are necessary but not sufficiently visible.
An overview of the reasons for 2.10 would go in the notes that go in the
announcement.
For initial binding, it's a different audience, but again top-level text
that points out the change.
Ditto internal graph simplification, and RIOT reader changes.
Andy
