On Thu, Sep 16, 2010 at 9:25 AM, Mattias Persson <[email protected]>wrote:
> 2010/9/15 Jacob Hansson <[email protected]> > > > On Wed, Sep 15, 2010 at 5:37 PM, Jacob Hansson <[email protected]> > > wrote: > > > > > Hi Alex, sorry this response took me so long, see responses inline! > > > > > > 2010/9/10 Alexandru Popescu ☀ <[email protected]> > > > > > > On Tuesday, September 7, 2010, Jacob Hansson <[email protected]> > > wrote: > > >> > 2010/9/6 Alexandru Popescu ☀ <[email protected]> > > >> > > > >> >> On Monday, September 6, 2010, Jim Webber <[email protected]> wrote: > > >> >> > Hi Alex, > > >> >> > > > >> >> >> While I still can achieve all these with the current packaging, > it > > >> >> >> feels more "hacky": I need to create a new Jetty6BasedWebServer > or > > >> >> >> modify the existing one to enhance it with my own stuff. Each > > change > > >> >> >> would require compiling and repackaging the whole neo4j-rest. > > >> >> >> Definitely not as easy as dropping in my own jar and a new > > web.xml. > > >> >> > > > >> >> > That's an interesting point. In a sense, the neo-rest package is > > >> Neo's > > >> >> REST package. > > >> >> > > >> >> Interesting... My main question is: what exactly is this package > > >> >> offering to the end user in the current form? IMO it cannot be an > > >> >> off-the-shelf product as there is no security. It is not a library > > >> >> either, as extending it is not so easy. Basically, and without any > > >> >> intention to harm any feelings, it looks like one of those dummy > "web > > >> >> UI interface to X". And I'd say it has much more potential than > that! > > >> >> > > >> >> > > >> > > >> Jacob, > > >> > > >> I must confess I'm totally confused by your comments below. > > >> > > >> > I've always seen it as the beginnings of a proper stand-alone neo4j > > >> server. > > >> > > >> If it is the beginning, then what comes next? And more importantly > > >> from whom? Basically my proposal was meant to make things easier for > > >> people to built on top of it, so I'm not really sure how you see the > > >> continuation of it. > > >> > > > > > > There is lots of cool things that can be done next. Both continuing to > > > extend the functionality of the REST server, but also (and more > > importantly) > > > to look at and help out with the work being done on clients for the > > server > > > in various languages. For instance I'd love to see simple-to-use ORMs > on > > top > > > of the python and php clients, enabling web developers to start > building > > > stuff with Neo4j as their database tier. > > > > > > > > > > Just to clarify (trying to keep my answers less confusing :) ): > > > > To answer the last portion of your question, I think making neo4j REST > more > > extensible is great (see my last answer). However, I read your initial > > proposal as an argument for viewing neo4j-rest as a library and for > > switching to a WAR packaging model. Both of which I strongly oppose *if* > it > > is done at the expense of the stand alone application. > > > > I don't think it's about making the standalone REST package into a WAR, but > to add a packaging as a war as another option to use the REST service. > There's really no reason not to have both packagings, or is there? > > Yeah, I think I very much misunderstood the scope of Alexandrus initial proposal - adding more packaging options, as well as making neo4j-rest easier to extend is a great idea :) > > > > > > >> > A REST/JSON API to Neo4j opens up for remote clients in any > language, > > >> and > > >> > would be an important part in matching offerings from other database > > >> > vendors. While extendability is a great thing, building it as a > > library > > >> > and/or packaging it as a WAR makes it very java-centric. > > >> > > > >> > > >> Currently the neo4j-rest is distributed as a java application. So it > > >> is java-centric. What makes it attractive is that it allows using the > > >> HTTP protocol. Providing neo4j-rest as both a self contained app and > > >> as a web app will give you exactly the same benefits, with additional > > >> freedom on choosing how to use it, what servers to deploy it too, etc. > > >> > > > > > > True, the neo4j-rest project is, but I see the biggest potential of the > > > REST project in it's stand-alone version, neo4j-rest-standalone. The > > reason > > > for that is precisely what I mentioned before, the fact that it is not > > java > > > centric. > > > > > > Distributing both as a WAR and as a stand-alone application sounds like > a > > > great solution! > > > > > > > > >> > > >> > Like you say, there is no security, and I agree it is currently the > > main > > >> > culprit stopping neo4j REST from production use. This can of course > be > > >> > offset with firewalling etc, but I couldn't agree more of the > > importance > > >> of > > >> > a proper security layer. > > >> > > > >> > > >> Security was used as a basic example of things that could be much > > >> easier to be added on top of the neo4j-rest if provided in a simpler > > >> format. As you probably know already firewalls will give you at most a > > >> very basic sort of authentication, but nothing else. > > >> > > > > > >> > As far as "UI interface to X" goes, the area to focus on I think is > > the > > >> JSON > > >> > part of the API. With that, a UI can be built in any language. Take > a > > >> look > > >> > at http://github.com/neo4j/webadmin for a more powerful browsing UI > > for > > >> > neo4j REST. > > >> > > > >> > > >> I think you mis-read my post. I'm not looking for a nice UI, but > > >> rather for a basis to further build REST services on top of a neo4j > > >> db. As Jim mentioned in his posts, currently neo4j-rest is just > > >> exposing the basics of a neo4j db. > > >> > > >> > > > It's true that the functionality exposed by neo4j-rest so far is fairly > > > basic. There are several important parts of the neo4j API that should > be > > > exposed via REST (like transactions). I don't see that as an argument > to > > > make neo4j-rest more extendable though, as I feel these core items > should > > be > > > added the same way the data browsing, index and traversal APIs have > been > > > added. > > > > > > That said - extendability would be a great thing, and there are ways to > > > make neo4j-rest much more accessible than it is today. I know Andreas > is > > > looking into the possibility of making neo4j-rest use OSGi-magic, which > > if > > > implemented would make it possible to hot-deploy extensions into > > neo4j-rest > > > as well as package extensions with it. > > > > > > I think the main reason of our disagreement (and my confusing answers > :) > > ) > > > is that we view neo4j-rest from two sides. I see it through the eyes of > a > > > web-developer. I'm used to having my database at some given port and a > > > client in my web tier that throws work at the database. You see it as a > > > powerful tool to easily expose the data part of an app via HTTP, to be > > > combined with other things exposed from the same app. > > > > > > I don't think there is a reason why neo4j-rest couldn't do both :) > > > > > > > > >> :- alex > > >> > > >> > > > >> > > > >> >> > However the notion of just letting end users write their own code > > >> hadn't > > >> >> occurred at least to me. I guess I always assumed that if users > > really > > >> >> wanted a domain specific API then they'd write their own. But the > > >> notion of > > >> >> user-registered filters (at least) is pretty sensible. > > >> >> > > > >> >> > > >> >> I think your initial assumption makes a lot of sense. But why would > > >> >> one have to duplicate all the work when this could provide him not > > >> >> only with a good example, but a common basis for a complete > solution. > > >> >> I'm looking at it from the perspective of a DB vizualization tool: > > >> >> what's in there offers you the default view. Next you could build > > your > > >> >> own views, etc. You could even build your complete application > using > > >> >> it. > > >> >> > > >> >> Best thing is that I don't even think it is difficult to get it > being > > >> >> more a matter of packaging than anything else. All would be needed: > > >> >> > > >> >> - a web.xml file with some configuration options in it (db > location) > > >> >> - providing better access to the GraphDatabaseService (see my > > previous > > >> >> suggestion) and other common shared resources (IndexService, etc) > > >> >> - a different final package in form of a war > > >> >> - done > > >> >> > > >> >> Does it make sense to you? > > >> >> > > >> >> :- alex > > >> >> > > >> >> > Jim > > >> >> > _______________________________________________ > > >> >> > Neo4j mailing list > > >> >> > [email protected] > > >> >> > https://lists.neo4j.org/mailman/listinfo/user > > >> >> > > > >> >> _______________________________________________ > > >> >> Neo4j mailing list > > >> >> [email protected] > > >> >> https://lists.neo4j.org/mailman/listinfo/user > > >> >> > > >> > > > >> > > > >> > > > >> > -- > > >> > Jacob Hansson > > >> > Phone: +46 (0) 763503395 > > >> > Twitter: @jakewins > > >> > _______________________________________________ > > >> > Neo4j mailing list > > >> > [email protected] > > >> > https://lists.neo4j.org/mailman/listinfo/user > > >> > > > >> _______________________________________________ > > >> Neo4j mailing list > > >> [email protected] > > >> https://lists.neo4j.org/mailman/listinfo/user > > >> > > > > > > > > > > > > -- > > > Jacob Hansson > > > Phone: +46 (0) 763503395 > > > Twitter: @jakewins > > > > > > > > > > > -- > > Jacob Hansson > > Phone: +46 (0) 763503395 > > Twitter: @jakewins > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > -- > Mattias Persson, [[email protected]] > Hacker, Neo Technology > www.neotechnology.com > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Jacob Hansson Phone: +46 (0) 763503395 Twitter: @jakewins _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
