Hi, I had a look at the open issues related to Fuseki. Here is the list: - https://issues.apache.org/jira/browse/JENA-162 (major) (Rob, does this need to be included in the first Fuseki release?) - https://issues.apache.org/jira/browse/JENA-218 (major) (... a patch from Alexander might come for this) - https://issues.apache.org/jira/browse/JENA-205 (minor) - https://issues.apache.org/jira/browse/JENA-171 (minor) - https://issues.apache.org/jira/browse/JENA-172 (minor) - https://issues.apache.org/jira/browse/JENA-214 (minor) - https://issues.apache.org/jira/browse/JENA-201 (minor) - https://issues.apache.org/jira/browse/JENA-220 (minor)
Is any of this a blocker for a first release? I am confused about JENA-220. Other than that, they all seems quite useful and reasonable. Two are flagged as 'major' but I have not looked in details how much work is needed yet. They don't seem to me to be 'blockers' for a release. What do you think? JENA-201, even if flagged as minor, I think it's quite important if we want to successfully allow Fuseki to be deployed and used in 'enterprisy' environments. In such places, you have an app server or a servlet container and that's it, no discussion, you need to use that (and therefore deploy via standard .war which we know are well supported by all the app server and/or servlet containers around. Fortunately!). Ok, it's not all places like this, but mostly... correct me if I am wrong. I had a look at JENA-201 and Andy's proposal of a "single dispatcher to work on URI patterns" seems, on paper, to be the best option. It allows us to take full control of requests dispatching and it minimizes, if not evict, any Jetty and/or other containers specific code. We just have our config and configure the dispatcher via standard web.xml. A lot of web framework and/or libraries which work in a web app do this way. It makes sense. Don't get me wrong, I like Jetty and the unzip and run approach. But we could (and should) support both scenarios: unzip and run as well as deploy a war in a servlet container. I opened JENA-214 and had a look at how it could be implemented. However, considering JENA-201, a solution depending on Jetty isn't the best option. A single dispatcher would allow us to easily control read-only/read-write mode for datasets as well and make JENA-214 simple to implement and portable across different servlet containers. The rationale behind JENA-214 is that this simple management function is the minimum to enable all sort of things which are useful in production environment. For example, one could easily deploy Fuseki on multiple machines in a master/slave configuration (similar to what Apache Solr and many other solutions used to do): you have one master which receive all your updates and as many slaves as you want to server your read requests. You achieve high-availability on the read path. The master is a single point of failures, if it goes down you cannot update. There might be a time gap between an update and when the update is available on all the slaves (but many use cases can live with that). Replication can be done externally to Fuseki, for example, using rsync. Backup is another very useful functionality and it is now included in Fuseki (kudos to Andy). I'll have a look at JENA-201 and make some experiments to see how feasible the "single dispatcher" is. There should not be much difference or implications in terms of performances right? Servlets are instantiated from a thread pool and so long no expensive objects are created on a per-request basis a single dispatcher should be ok, right? Anyway, I'll come back this when I look (*) at it more. Paolo PS: (*) 'looking' does not mean "assign the issue to me". I am not sure I have time for it and/or I am best positioned to fix it with the best solution. But, I want to learn and understand how it can be done and I think it's important, therefore: I am looking into it. :-)
