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! > > I've always seen it as the beginnings of a proper stand-alone neo4j server. 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.
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. 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. > > 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
