- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Sat, 12 Sep 2015 16:38:40 +0200
- To: Nicola Greco <me@nicolagreco.com>
- Cc: bergi <bergi@axolotlfarm.org>, Melvin Carvalho <melvincarvalho@gmail.com>, "public-rdfjs@w3.org" <public-rdfjs@w3.org>, Adrian Gschwend <ktk@netlabs.org>, me@nicola.io, dr@jones.dk
Hi Nicola, > 1) Interoperability. We can work on the same library, but what we should do - really - is to work on the same spec. +1 for this, regardless of other outcomes. But this would require us to talk about such a spec together. For instance: callbacks / promises / streams / (async) iterators? And several other questions, notably: how to model a triple? > 2) Modularization. We can work on one unique library Yes, but is such an approach proven to work? > but we would gain much more by decomposing all of our libraries I think we should make a much closer pro/con analysis to be able to conclude that. It depends on the definition of "gain" as well. Performance we won't gain, I'd imagine. > The interesting thing of RDF-Ext is that when it will be completely modularized, then its scheleton would be incredibly thin for everyone to personalize it. +1 But still… some centralized coordination would not be bad. It's not clear to me now who decides on RDF-Ext, and how we could influence that. Can we discuss somewhere about the essentials? How do we get involved with the RDF-Ext core? I have the impression that the current scattering of things (store here, parser there, query engine somewhere else) mostly brings the disadvantages of modularization, not the advantages. And I'd happy make my libraries RDF-Ext modules, but then I'd like to be involved in the core design as well. Best, Ruben
Received on Saturday, 12 September 2015 14:39:14 UTC