I see your point and I think that it'd be a good idea to have the ability to build/download a .war file for convenience, in addition to the current format. I don't really see any arguments against it at least. And it should be a fairly easy task to create such an assembly.
2010/9/10, Alexandru Popescu ☀ <the.mindstorm.mailingl...@gmail.com>: > On Tuesday, September 7, 2010, Jacob Hansson <ja...@voltvoodoo.com> wrote: >> 2010/9/6 Alexandru Popescu ☀ <the.mindstorm.mailingl...@gmail.com> >> >>> On Monday, September 6, 2010, Jim Webber <j...@webber.name> 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. > >> 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. > >> 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. > > :- 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 >>> > User@lists.neo4j.org >>> > https://lists.neo4j.org/mailman/listinfo/user >>> > >>> _______________________________________________ >>> Neo4j mailing list >>> User@lists.neo4j.org >>> https://lists.neo4j.org/mailman/listinfo/user >>> >> >> >> >> -- >> Jacob Hansson >> Phone: +46 (0) 763503395 >> Twitter: @jakewins >> _______________________________________________ >> Neo4j mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user >> > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
