jena-ldp

[Andy Seaborne <an...@apache.org>]

On 14/02/17 14:43, A. Soroka wrote:
>
>> On Feb 14, 2017, at 7:26 AM, Andy Seaborne <an...@apache.org> wrote:
>>
>> Nowadays, I think it is better to develop new capabilities through clones and dynamic PRs and better to keep the main code repository as focused on the main line of development so I propose deleting branches and closing JIRA as noted above.
>
> +1
>
> I have just rebased ThreadPerGraphDataset (sorry about the slew of commit msgs!).
>
> I would like to land that branch, but we did not come to a conclusion here:
>
> https://github.com/apache/jena/pull/204
>
> that I could find about how to do that. Andy remarked:
>
>> 	\u2022 "Small things" being curated go into a general jena-extras/jena-wip/jena-labs/jena-optional module with the idea that that is just while they mature, Downside: things go into that module and don't progress.
>> 	\u2022 At the other end of the spectrum, this is a step for jena-ldp so to get attention on that, use that name. Downside: over selling.
>> 	\u2022 Specific for this one thing: jena-writer-dsg, a name for the write-centric dataset. Downside: does not connect to LDP usage.
>
>

Then there are a couple of comments about design and jena-ldp overall. 
I took away from that that ThreadPerGraphDataset is in-progress - I 
think it would be better to know it is the right design for whatever 
it's use case is before putting into a jena release. It gives more 
freedom to change without worrying about incompatibility.

Once released there is an obligation which can be limiting (despite any 
words around it to say "may change").


> Thoughts? Is anyone else interested in bring an optional LDP component to Fuseki (or perhaps independently of Fuseki, a la jena-ldp)?

Its easy enough to build a Fuseki with more code loaded into it. That's 
what [1] does. Copy the Fuseki shaded POM pattern.

Or put the Fuseki combined jar on the classpath (-cp, not -jar) =- that 
works as well.  As Fuseki has all the cmds inside it, it's a convenient 
way to work on a remote server.

     Andy

[1]
https://github.com/afs/mantis/blob/master/fuseki-tdb2/pom.xml




>
> ---
> A. Soroka
> The University of Virginia Library
>

Re: jena-ldp

["A. Soroka" <aj...@virginia.edu>]

> On Feb 15, 2017, at 4:10 PM, Andy Seaborne <an...@apache.org> wrote:
> 
> 
> Then there are a couple of comments about design and jena-ldp overall. I took away from that that ThreadPerGraphDataset is in-progress - I think it would be better to know it is the right design for whatever it's use case is before putting into a jena release. It gives more freedom to change without worrying about incompatibility.
> 
> Once released there is an obligation which can be limiting (despite any words around it to say "may change").

Well, the code as it stands is (I think) okay-- but where does it stand within Jena? :grin:

I'm going to close that PR and move the branch over to my Github clone. There are at least two possibilities here: evolve it towards some kind of jena-ldp, or expand it to try to tackle variable lock regions and a more general in-memory multiwriter setup. Either deserve their own threads of discussion.

---
A. Soroka
The University of Virginia Library