Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/43
You may have better ideas on how to do something like
[ParserConfigImpl](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/ParserCo
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Thanks, @ajs6f !
I found some old code where I had tried to make a fluent interface.. I
managed to update it to the current master and sorted some issues.
I pushed it to the `fluen
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Okay, I'll get to work on factoring out a (serializable) factory. Thanks
for the discussion everyone! I think the parser types will be much stronger for
it.
---
-
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Hm... if @afs and @stain are both feeling reluctant to go this way... I
would still be happy to merge it as-is and then work forward to the fluent-ish
factory design (since @ansell has given a LGTM
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Picking up this - @ajs6f do you still think we should proceed along those
lines? I am also reluctant to making the abstract factory (builder)
serializable, but I can see the reasoning, particularly
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
@wikier My sense is that the right move here immediately is to merge this
PR and then open a ticket to factor config (and a builder therefor) out of
`AbstractRDFParser`. (A ticket I will be happy t
Github user ansell commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Having ``Optional`` fields isn't impossible to serialise (as I said
erroneously in the referenced comment), as you could always write custom
serialise/deserialise code to support it, but it isn't
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
ð
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.
Github user wikier commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Having a little understanding on the concrete use case behind this PR,
generally speaking I normally prefer having the factories/builders implementing
`Serializable`. So in this concrete case I pr
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
I'd like to get @wikier an answer to his question. It sounds like we are
_not_ comfortable merging this for `RC2` and he should go ahead without it,
correct?
If the consensus is that seri
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Agree with @afs that only the builder-factory bit should be serialized -
obviously the actual parser which may be in progress of parsing is tricky to
serialize. So we would need to perhaps clean up
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
So the question is whether what is here now is a step forward.
I think it is, and I would want to do what is here whether or not we go
onto a builder factoring. I intentionally did not add
Github user afs commented on the issue:
https://github.com/apache/commons-rdf/pull/43
All I did was point out that it isn't logically serializable at all points
in its usage.
My suggestion is that there is design with a builder (serializable) and
instance (not serializable)
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
My impression is that @afs objects to the current design, but I haven't
heard feedback on [my
suggestion](https://github.com/apache/commons-rdf/pull/43#issuecomment-341721718).
---
-
Github user wikier commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Now that we have aborted `0.5.0-RC1`, do you think this should go in `RC2`?
Honestly I have no much background to really have an opinion on this PR.
---
-
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Well, it's hard for me to say, because I'm trying to predict the
architecture of a system I am only beginning to design. :(
@afs, @sebbASF, how about I break out a separate type for serial
Github user afs commented on the issue:
https://github.com/apache/commons-rdf/pull/43
AbstractRDFParser is stateful at some points in its lifecycle - input
stream and the threadpool/futures.
Is this mixing a builder for the configuration, where serialization makes
sense, with
Github user ajs6f commented on the issue:
https://github.com/apache/commons-rdf/pull/43
From my POV, serializing a parser is useful for very long or very large ETL
when you may need to either pause and resume parsing (persisting the state of
the task in between) or move parsing tasks
Github user afs commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Relaying a question from sebb on the JIRA:
https://issues.apache.org/jira/browse/COMMONSRDF-49#comment-16236065 including
pointing out the long term restriction that comes with it.
---
---
19 matches
Mail list logo
