Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Ok,
then let's shelf this until further notice, and revise it when we have
done some more extensive work on the server and fast protocol stack.

Thanks for all input, good that you speak up!

Cheers,

/peter neubauer

GTalk:      neubauer.peter
Skype       peter.neubauer
Phone       +46 704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter      http://twitter.com/peterneubauer

http://www.neo4j.org              - NOSQL for the Enterprise.
http://startupbootcamp.org/    - Öresund - Innovation happens HERE.



On Wed, Nov 2, 2011 at 8:53 AM, Michael Hunger
 wrote:
> As I said it is still used in the rest-graphdb-client which comes as a 
> drop-in-replacement for the core-api.
>
> This functionality would go missing then.
>
> Same goes for lot of stuff that for instance neography does with the REST 
> server to offer a quite fluent way of traversing the graph.
>
> See here: https://github.com/maxdemarzi/neography -> Readme
>
> n1.outgoing(:friends).incoming(:enemies)                  # Get nodes related 
> by one of multiple relationships
> n1.outgoing(:friends).depth(2)                                       # Get 
> nodes related by friends and friends of friends
> n1.outgoing(:friends).depth(:all)                                    # Get 
> nodes related by friends until the end of the graph
> n1.outgoing(:friends).depth(2).include_start_node   # Get n1 and nodes 
> related by friends and friends of friends
>
> n1.outgoing(:friends).prune("position.endNode().getProperty('name') == 
> 'Tom';")
> n1.outgoing(:friends).filter("position.length() == 2;")
>
> We use this functionality also in our hosting provider to navigate the graph 
> of servers, providers, users, databases and servers.
>
> If it goes away we have to rewrite parts of the hosting provider in something 
> else.
>
> Cheers
>
> Michael
>
> Am 02.11.2011 um 16:41 schrieb Peter Neubauer:
>
>> Yes.
>> This thread is about ONLY the traverse-Endpoint not scripting in general.
>>
>> Cheers,
>>
>> /peter neubauer
>>
>> GTalk:      neubauer.peter
>> Skype       peter.neubauer
>> Phone       +46 704 106975
>> LinkedIn   http://www.linkedin.com/in/neubauer
>> Twitter      http://twitter.com/peterneubauer
>>
>> http://www.neo4j.org              - NOSQL for the Enterprise.
>> http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
>>
>>
>>
>> On Wed, Nov 2, 2011 at 8:35 AM, Jacob Hansson
>>  wrote:
>>> On Wed, Nov 2, 2011 at 3:44 PM, Peter Neubauer <
>>> peter.neuba...@neotechnology.com> wrote:
>>>
 Mmh,
 this thread is just about deprecating the travers() section of the
 REST API, not take away general scripting form the server. I have not
 seen one single case where people have exploited the JavaScript
 exposure in the return/stop evaluators to do anything like you say
 Michael.

 Extensions and plugins are not going away for the time being, I am
 only concerned about
 http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html not
 adding value to the API, and being able to be scripted in a more
 concise way via the existing extensions (which I want to make examples
 of).

 I haven't heard any argument for this case, so the question is whether
 to document the usecases in other ways (Groovy, JavaScript or Cypher
 plugins) and deprecate this section, since it doesn't add
 functionality, just exposes scripting in a hacked-up way.

>>>
>>> Good that you point this out, this thread is a bit confusing since we're
>>> talking about a lot of different things. If we can't find use cases that
>>> warrants the REST traversal API, we should deprecate it. It would be great
>>> to get the input of some of the people working on clients for the REST
>>> server before a decision is made though.
>>>
>>>
>>> I would also *really* like to continue the discussion about arbitrary
>>> script execution, because I want to understand the arguments for it.
>>> Perhaps we should break that discussion into a separate thread, to keep
>>> things concise.
>>>
>>> Imma start a new thread :)
>>>
>>>

 Cheers,

 /peter neubauer

 GTalk:      neubauer.peter
 Skype       peter.neubauer
 Phone       +46 704 106975
 LinkedIn   http://www.linkedin.com/in/neubauer
 Twitter      http://twitter.com/peterneubauer

 http://www.neo4j.org              - NOSQL for the Enterprise.
 http://startupbootcamp.org/    - Öresund - Innovation happens HERE.



 On Wed, Nov 2, 2011 at 3:11 AM, Michael Hunger
  wrote:
> custom use-cases like the ones implemented by our customers with plugins
 / extensions
>
> and in the case of the ruby script extensions a way I'd like to promote
 to talk to the server that is
>
> 1) create you own RESTful endpoints that are focused on a protocol
 speaking your domain and not nodes + rels
> 2) the protocol is use-case oriented
> 3) it only transmits the information neces

Re: [Neo4j] REST traverse deprecation

[Michael Hunger]

As I said it is still used in the rest-graphdb-client which comes as a 
drop-in-replacement for the core-api.

This functionality would go missing then.

Same goes for lot of stuff that for instance neography does with the REST 
server to offer a quite fluent way of traversing the graph.

See here: https://github.com/maxdemarzi/neography -> Readme

n1.outgoing(:friends).incoming(:enemies)  # Get nodes related 
by one of multiple relationships
n1.outgoing(:friends).depth(2)   # Get 
nodes related by friends and friends of friends
n1.outgoing(:friends).depth(:all)# Get 
nodes related by friends until the end of the graph
n1.outgoing(:friends).depth(2).include_start_node   # Get n1 and nodes related 
by friends and friends of friends

n1.outgoing(:friends).prune("position.endNode().getProperty('name') == 'Tom';")
n1.outgoing(:friends).filter("position.length() == 2;")

We use this functionality also in our hosting provider to navigate the graph of 
servers, providers, users, databases and servers.

If it goes away we have to rewrite parts of the hosting provider in something 
else.

Cheers

Michael

Am 02.11.2011 um 16:41 schrieb Peter Neubauer:

> Yes.
> This thread is about ONLY the traverse-Endpoint not scripting in general.
> 
> Cheers,
> 
> /peter neubauer
> 
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
> 
> http://www.neo4j.org  - NOSQL for the Enterprise.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> 
> 
> 
> On Wed, Nov 2, 2011 at 8:35 AM, Jacob Hansson
>  wrote:
>> On Wed, Nov 2, 2011 at 3:44 PM, Peter Neubauer <
>> peter.neuba...@neotechnology.com> wrote:
>> 
>>> Mmh,
>>> this thread is just about deprecating the travers() section of the
>>> REST API, not take away general scripting form the server. I have not
>>> seen one single case where people have exploited the JavaScript
>>> exposure in the return/stop evaluators to do anything like you say
>>> Michael.
>>> 
>>> Extensions and plugins are not going away for the time being, I am
>>> only concerned about
>>> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html not
>>> adding value to the API, and being able to be scripted in a more
>>> concise way via the existing extensions (which I want to make examples
>>> of).
>>> 
>>> I haven't heard any argument for this case, so the question is whether
>>> to document the usecases in other ways (Groovy, JavaScript or Cypher
>>> plugins) and deprecate this section, since it doesn't add
>>> functionality, just exposes scripting in a hacked-up way.
>>> 
>> 
>> Good that you point this out, this thread is a bit confusing since we're
>> talking about a lot of different things. If we can't find use cases that
>> warrants the REST traversal API, we should deprecate it. It would be great
>> to get the input of some of the people working on clients for the REST
>> server before a decision is made though.
>> 
>> 
>> I would also *really* like to continue the discussion about arbitrary
>> script execution, because I want to understand the arguments for it.
>> Perhaps we should break that discussion into a separate thread, to keep
>> things concise.
>> 
>> Imma start a new thread :)
>> 
>> 
>>> 
>>> Cheers,
>>> 
>>> /peter neubauer
>>> 
>>> GTalk:  neubauer.peter
>>> Skype   peter.neubauer
>>> Phone   +46 704 106975
>>> LinkedIn   http://www.linkedin.com/in/neubauer
>>> Twitter  http://twitter.com/peterneubauer
>>> 
>>> http://www.neo4j.org  - NOSQL for the Enterprise.
>>> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>>> 
>>> 
>>> 
>>> On Wed, Nov 2, 2011 at 3:11 AM, Michael Hunger
>>>  wrote:
 custom use-cases like the ones implemented by our customers with plugins
>>> / extensions
 
 and in the case of the ruby script extensions a way I'd like to promote
>>> to talk to the server that is
 
 1) create you own RESTful endpoints that are focused on a protocol
>>> speaking your domain and not nodes + rels
 2) the protocol is use-case oriented
 3) it only transmits the information necessary (not more).
 4) The code of these endpoints would be transactionally executed
 
 Use-Cases with customers so far have been:
 * unique nodes with locking + index lookup
 * batch data insertion (also unique stuff see above)
 * custom traversals with complicated callbacks
 * aggregating multiple gremlin / cypher queries in the server and
>>> returning only a partial result-set/projection of those executions
 * 
 
 With the ruby script extension what we've done there is to leverage the
>>> web/REST frameworks of the platform and allow rack-apps to expose their
>>> REST endpoints within the neo4j-server.
 
 Thomas and I also talked about a m

Re: [Neo4j] REST traverse deprecation

[Kevin Dieter]

Hi,

We use the REST traversal API extensively.  One of our core use cases is to
find all paths between two nodes.  We are a .Net shop so we rely on the
REST API, and are currently using a .Net neo4j library from about 18 months
ago that we have customized to our needs.

I have seen other recent threads about updated .Net libraries so that is on
our roadmap.

We are currently on v1.4.1 so if the REST traversal API is deprecated in a
future version, that will drive a fairly significant change on our system
to replace the .Net library and refactor the traversal functionality
accordingly.  I generally think this is a good thing since we need to move
in that directly anyways, but I wanted to at least get it out that we use
the REST traversal API.

Thanks,

Kevin

On Wed, Nov 2, 2011 at 11:35 AM, Jacob Hansson <
jacob.hans...@neotechnology.com> wrote:

> On Wed, Nov 2, 2011 at 3:44 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
>
> > Mmh,
> > this thread is just about deprecating the travers() section of the
> > REST API, not take away general scripting form the server. I have not
> > seen one single case where people have exploited the JavaScript
> > exposure in the return/stop evaluators to do anything like you say
> > Michael.
> >
> > Extensions and plugins are not going away for the time being, I am
> > only concerned about
> > http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html not
> > adding value to the API, and being able to be scripted in a more
> > concise way via the existing extensions (which I want to make examples
> > of).
> >
> > I haven't heard any argument for this case, so the question is whether
> > to document the usecases in other ways (Groovy, JavaScript or Cypher
> > plugins) and deprecate this section, since it doesn't add
> > functionality, just exposes scripting in a hacked-up way.
> >
>
> Good that you point this out, this thread is a bit confusing since we're
> talking about a lot of different things. If we can't find use cases that
> warrants the REST traversal API, we should deprecate it. It would be great
> to get the input of some of the people working on clients for the REST
> server before a decision is made though.
>
>
> I would also *really* like to continue the discussion about arbitrary
> script execution, because I want to understand the arguments for it.
> Perhaps we should break that discussion into a separate thread, to keep
> things concise.
>
> Imma start a new thread :)
>
>
> >
> > Cheers,
> >
> > /peter neubauer
> >
> > GTalk:  neubauer.peter
> > Skype   peter.neubauer
> > Phone   +46 704 106975
> > LinkedIn   http://www.linkedin.com/in/neubauer
> > Twitter  http://twitter.com/peterneubauer
> >
> > http://www.neo4j.org  - NOSQL for the Enterprise.
> > http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> >
> >
> >
> > On Wed, Nov 2, 2011 at 3:11 AM, Michael Hunger
> >  wrote:
> > > custom use-cases like the ones implemented by our customers with
> plugins
> > / extensions
> > >
> > > and in the case of the ruby script extensions a way I'd like to promote
> > to talk to the server that is
> > >
> > > 1) create you own RESTful endpoints that are focused on a protocol
> > speaking your domain and not nodes + rels
> > > 2) the protocol is use-case oriented
> > > 3) it only transmits the information necessary (not more).
> > > 4) The code of these endpoints would be transactionally executed
> > >
> > > Use-Cases with customers so far have been:
> > > * unique nodes with locking + index lookup
> > > * batch data insertion (also unique stuff see above)
> > > * custom traversals with complicated callbacks
> > > * aggregating multiple gremlin / cypher queries in the server and
> > returning only a partial result-set/projection of those executions
> > > * 
> > >
> > > With the ruby script extension what we've done there is to leverage the
> > web/REST frameworks of the platform and allow rack-apps to expose their
> > REST endpoints within the neo4j-server.
> > >
> > > Thomas and I also talked about a more generic way to allow any language
> > supported by the javax.script extension to register endpoints with the
> > neo4j-server.
> > >
> > > A generic javax.scripting languages plugin would accommodate for more
> > ad-hoc execution mode for which writing an extension is too much
> ceremony.
> > >
> > > Michael
> > >
> > >
> > > Am 02.11.2011 um 10:54 schrieb Jacob Hansson:
> > >
> > >> On Wed, Nov 2, 2011 at 10:20 AM, Michael Hunger <
> > >> michael.hun...@neotechnology.com> wrote:
> > >>
> > >>> I vote not dropped, as there are lots of non-java developers out
> there
> > >>> which would want to use REST server dynamically.
> > >>>
> > >>
> > >> I am completely open to the notion that I am wrong here. But I want us
> > to
> > >> have answered the questions I was asking before properly, if we are
> > going
> > >> to embrace all these ways to talk to the server.
> > >>
> > >>
> > >> What use cases does dy

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Yes.
This thread is about ONLY the traverse-Endpoint not scripting in general.

Cheers,

/peter neubauer

GTalk:      neubauer.peter
Skype       peter.neubauer
Phone       +46 704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter      http://twitter.com/peterneubauer

http://www.neo4j.org              - NOSQL for the Enterprise.
http://startupbootcamp.org/    - Öresund - Innovation happens HERE.



On Wed, Nov 2, 2011 at 8:35 AM, Jacob Hansson
 wrote:
> On Wed, Nov 2, 2011 at 3:44 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
>
>> Mmh,
>> this thread is just about deprecating the travers() section of the
>> REST API, not take away general scripting form the server. I have not
>> seen one single case where people have exploited the JavaScript
>> exposure in the return/stop evaluators to do anything like you say
>> Michael.
>>
>> Extensions and plugins are not going away for the time being, I am
>> only concerned about
>> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html not
>> adding value to the API, and being able to be scripted in a more
>> concise way via the existing extensions (which I want to make examples
>> of).
>>
>> I haven't heard any argument for this case, so the question is whether
>> to document the usecases in other ways (Groovy, JavaScript or Cypher
>> plugins) and deprecate this section, since it doesn't add
>> functionality, just exposes scripting in a hacked-up way.
>>
>
> Good that you point this out, this thread is a bit confusing since we're
> talking about a lot of different things. If we can't find use cases that
> warrants the REST traversal API, we should deprecate it. It would be great
> to get the input of some of the people working on clients for the REST
> server before a decision is made though.
>
>
> I would also *really* like to continue the discussion about arbitrary
> script execution, because I want to understand the arguments for it.
> Perhaps we should break that discussion into a separate thread, to keep
> things concise.
>
> Imma start a new thread :)
>
>
>>
>> Cheers,
>>
>> /peter neubauer
>>
>> GTalk:      neubauer.peter
>> Skype       peter.neubauer
>> Phone       +46 704 106975
>> LinkedIn   http://www.linkedin.com/in/neubauer
>> Twitter      http://twitter.com/peterneubauer
>>
>> http://www.neo4j.org              - NOSQL for the Enterprise.
>> http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
>>
>>
>>
>> On Wed, Nov 2, 2011 at 3:11 AM, Michael Hunger
>>  wrote:
>> > custom use-cases like the ones implemented by our customers with plugins
>> / extensions
>> >
>> > and in the case of the ruby script extensions a way I'd like to promote
>> to talk to the server that is
>> >
>> > 1) create you own RESTful endpoints that are focused on a protocol
>> speaking your domain and not nodes + rels
>> > 2) the protocol is use-case oriented
>> > 3) it only transmits the information necessary (not more).
>> > 4) The code of these endpoints would be transactionally executed
>> >
>> > Use-Cases with customers so far have been:
>> > * unique nodes with locking + index lookup
>> > * batch data insertion (also unique stuff see above)
>> > * custom traversals with complicated callbacks
>> > * aggregating multiple gremlin / cypher queries in the server and
>> returning only a partial result-set/projection of those executions
>> > * 
>> >
>> > With the ruby script extension what we've done there is to leverage the
>> web/REST frameworks of the platform and allow rack-apps to expose their
>> REST endpoints within the neo4j-server.
>> >
>> > Thomas and I also talked about a more generic way to allow any language
>> supported by the javax.script extension to register endpoints with the
>> neo4j-server.
>> >
>> > A generic javax.scripting languages plugin would accommodate for more
>> ad-hoc execution mode for which writing an extension is too much ceremony.
>> >
>> > Michael
>> >
>> >
>> > Am 02.11.2011 um 10:54 schrieb Jacob Hansson:
>> >
>> >> On Wed, Nov 2, 2011 at 10:20 AM, Michael Hunger <
>> >> michael.hun...@neotechnology.com> wrote:
>> >>
>> >>> I vote not dropped, as there are lots of non-java developers out there
>> >>> which would want to use REST server dynamically.
>> >>>
>> >>
>> >> I am completely open to the notion that I am wrong here. But I want us
>> to
>> >> have answered the questions I was asking before properly, if we are
>> going
>> >> to embrace all these ways to talk to the server.
>> >>
>> >>
>> >> What use cases does dynamic script execution cover that cypher or
>> gremlin
>> >> do not?
>> >>
>> >> Why should those use cases not be covered by cypher or gremlin?
>> >>
>> >>
>> >>
>> >>>
>> >>> That was the reason why we wrote the ruby-script-extension support.
>> >>>
>> >>> Michael
>> >>>
>> >>> Am 02.11.2011 um 10:08 schrieb Jacob Hansson:
>> >>>
>>  On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
>>  peter.neuba...@neotechnology.com> wrote:
>> 
>> > Well,
>> > I think that C

Re: [Neo4j] REST traverse deprecation

[Jacob Hansson]

On Wed, Nov 2, 2011 at 3:44 PM, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:

> Mmh,
> this thread is just about deprecating the travers() section of the
> REST API, not take away general scripting form the server. I have not
> seen one single case where people have exploited the JavaScript
> exposure in the return/stop evaluators to do anything like you say
> Michael.
>
> Extensions and plugins are not going away for the time being, I am
> only concerned about
> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html not
> adding value to the API, and being able to be scripted in a more
> concise way via the existing extensions (which I want to make examples
> of).
>
> I haven't heard any argument for this case, so the question is whether
> to document the usecases in other ways (Groovy, JavaScript or Cypher
> plugins) and deprecate this section, since it doesn't add
> functionality, just exposes scripting in a hacked-up way.
>

Good that you point this out, this thread is a bit confusing since we're
talking about a lot of different things. If we can't find use cases that
warrants the REST traversal API, we should deprecate it. It would be great
to get the input of some of the people working on clients for the REST
server before a decision is made though.


I would also *really* like to continue the discussion about arbitrary
script execution, because I want to understand the arguments for it.
Perhaps we should break that discussion into a separate thread, to keep
things concise.

Imma start a new thread :)


>
> Cheers,
>
> /peter neubauer
>
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
>
> http://www.neo4j.org  - NOSQL for the Enterprise.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>
>
>
> On Wed, Nov 2, 2011 at 3:11 AM, Michael Hunger
>  wrote:
> > custom use-cases like the ones implemented by our customers with plugins
> / extensions
> >
> > and in the case of the ruby script extensions a way I'd like to promote
> to talk to the server that is
> >
> > 1) create you own RESTful endpoints that are focused on a protocol
> speaking your domain and not nodes + rels
> > 2) the protocol is use-case oriented
> > 3) it only transmits the information necessary (not more).
> > 4) The code of these endpoints would be transactionally executed
> >
> > Use-Cases with customers so far have been:
> > * unique nodes with locking + index lookup
> > * batch data insertion (also unique stuff see above)
> > * custom traversals with complicated callbacks
> > * aggregating multiple gremlin / cypher queries in the server and
> returning only a partial result-set/projection of those executions
> > * 
> >
> > With the ruby script extension what we've done there is to leverage the
> web/REST frameworks of the platform and allow rack-apps to expose their
> REST endpoints within the neo4j-server.
> >
> > Thomas and I also talked about a more generic way to allow any language
> supported by the javax.script extension to register endpoints with the
> neo4j-server.
> >
> > A generic javax.scripting languages plugin would accommodate for more
> ad-hoc execution mode for which writing an extension is too much ceremony.
> >
> > Michael
> >
> >
> > Am 02.11.2011 um 10:54 schrieb Jacob Hansson:
> >
> >> On Wed, Nov 2, 2011 at 10:20 AM, Michael Hunger <
> >> michael.hun...@neotechnology.com> wrote:
> >>
> >>> I vote not dropped, as there are lots of non-java developers out there
> >>> which would want to use REST server dynamically.
> >>>
> >>
> >> I am completely open to the notion that I am wrong here. But I want us
> to
> >> have answered the questions I was asking before properly, if we are
> going
> >> to embrace all these ways to talk to the server.
> >>
> >>
> >> What use cases does dynamic script execution cover that cypher or
> gremlin
> >> do not?
> >>
> >> Why should those use cases not be covered by cypher or gremlin?
> >>
> >>
> >>
> >>>
> >>> That was the reason why we wrote the ruby-script-extension support.
> >>>
> >>> Michael
> >>>
> >>> Am 02.11.2011 um 10:08 schrieb Jacob Hansson:
> >>>
>  On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
>  peter.neuba...@neotechnology.com> wrote:
> 
> > Well,
> > I think that Cypher is not yes taking into account Uniqueness, or is
> > it Andres? Otherwise, most of the normal traversals are covered.
> >
> > To keep things consistent and give people a way of doing fine grained
> > traversals, I would then suggest to document all the existing
> examples
> > using Cypher or Groovy code, so we can document that things are
> > working as expected and not loose functionality.
> >
> 
>  Sounds like a really good idea.
> 
> 
> >
> > The JavaScript exposure then would totally go away from the REST API
> > and possibly be facto

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Mmh,
this thread is just about deprecating the travers() section of the
REST API, not take away general scripting form the server. I have not
seen one single case where people have exploited the JavaScript
exposure in the return/stop evaluators to do anything like you say
Michael.

Extensions and plugins are not going away for the time being, I am
only concerned about
http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html not
adding value to the API, and being able to be scripted in a more
concise way via the existing extensions (which I want to make examples
of).

I haven't heard any argument for this case, so the question is whether
to document the usecases in other ways (Groovy, JavaScript or Cypher
plugins) and deprecate this section, since it doesn't add
functionality, just exposes scripting in a hacked-up way.

Cheers,

/peter neubauer

GTalk:      neubauer.peter
Skype       peter.neubauer
Phone       +46 704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter      http://twitter.com/peterneubauer

http://www.neo4j.org              - NOSQL for the Enterprise.
http://startupbootcamp.org/    - Öresund - Innovation happens HERE.



On Wed, Nov 2, 2011 at 3:11 AM, Michael Hunger
 wrote:
> custom use-cases like the ones implemented by our customers with plugins / 
> extensions
>
> and in the case of the ruby script extensions a way I'd like to promote to 
> talk to the server that is
>
> 1) create you own RESTful endpoints that are focused on a protocol speaking 
> your domain and not nodes + rels
> 2) the protocol is use-case oriented
> 3) it only transmits the information necessary (not more).
> 4) The code of these endpoints would be transactionally executed
>
> Use-Cases with customers so far have been:
> * unique nodes with locking + index lookup
> * batch data insertion (also unique stuff see above)
> * custom traversals with complicated callbacks
> * aggregating multiple gremlin / cypher queries in the server and returning 
> only a partial result-set/projection of those executions
> * 
>
> With the ruby script extension what we've done there is to leverage the 
> web/REST frameworks of the platform and allow rack-apps to expose their REST 
> endpoints within the neo4j-server.
>
> Thomas and I also talked about a more generic way to allow any language 
> supported by the javax.script extension to register endpoints with the 
> neo4j-server.
>
> A generic javax.scripting languages plugin would accommodate for more ad-hoc 
> execution mode for which writing an extension is too much ceremony.
>
> Michael
>
>
> Am 02.11.2011 um 10:54 schrieb Jacob Hansson:
>
>> On Wed, Nov 2, 2011 at 10:20 AM, Michael Hunger <
>> michael.hun...@neotechnology.com> wrote:
>>
>>> I vote not dropped, as there are lots of non-java developers out there
>>> which would want to use REST server dynamically.
>>>
>>
>> I am completely open to the notion that I am wrong here. But I want us to
>> have answered the questions I was asking before properly, if we are going
>> to embrace all these ways to talk to the server.
>>
>>
>> What use cases does dynamic script execution cover that cypher or gremlin
>> do not?
>>
>> Why should those use cases not be covered by cypher or gremlin?
>>
>>
>>
>>>
>>> That was the reason why we wrote the ruby-script-extension support.
>>>
>>> Michael
>>>
>>> Am 02.11.2011 um 10:08 schrieb Jacob Hansson:
>>>
 On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
 peter.neuba...@neotechnology.com> wrote:

> Well,
> I think that Cypher is not yes taking into account Uniqueness, or is
> it Andres? Otherwise, most of the normal traversals are covered.
>
> To keep things consistent and give people a way of doing fine grained
> traversals, I would then suggest to document all the existing examples
> using Cypher or Groovy code, so we can document that things are
> working as expected and not loose functionality.
>

 Sounds like a really good idea.


>
> The JavaScript exposure then would totally go away from the REST API
> and possibly be factored out into a plugin like Groovy/Gremlin. Or
> dropped.
>

 I vote dropped :)


>
> WDYT?
>
> Cheers,
>
> /peter neubauer
>
> GTalk:      neubauer.peter
> Skype       peter.neubauer
> Phone       +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter      http://twitter.com/peterneubauer
>
> http://www.neo4j.org              - NOSQL for the Enterprise.
> http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
>
>
>
> On Tue, Nov 1, 2011 at 9:31 AM, Jacob Hansson
>  wrote:
>> On Tue, Nov 1, 2011 at 5:22 PM, Peter Neubauer <
>> peter.neuba...@neotechnology.com> wrote:
>>
>>> Nope,
>>> I mean a server side script execution (which we already are doing in
>>> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
>>>

Re: [Neo4j] REST traverse deprecation

[Jacob Hansson]

On Wed, Nov 2, 2011 at 12:34 PM, Andres Taylor <
andres.tay...@neotechnology.com> wrote:

> On Wed, Nov 2, 2011 at 11:56 AM, Jacob Hansson <
> jacob.hans...@neotechnology.com> wrote:
>
> > On Wed, Nov 2, 2011 at 11:11 AM, Michael Hunger <
> > michael.hun...@neotechnology.com> wrote:
> >
> > > * custom traversals with complicated callbacks
> > >
> >
> > This is really what my original question to Peter was about - what are
> some
> > traversals like this, that we currently cannot do with Cypher or Gremlin?
> > Can we extend Cypher to accomodate those use cases?
>
>
> Well, Gremlin is just Groovy+Pipes, so there's nothing you can't do in
> Gremlin.
>
> If we're talking about Cypher, I have one for you: PageRank. PageRank
> iterates over the data set a specified number of times, marking and
> updating stuff on the fly, until it's happy and returns a result. It's not
> hard at all to write using Gremlin, but impossible with Cypher. I can't see
> a way to make that nice and easy with Cypher.
>

START a=node(1)
MATCH p = a-[1..100]-other
RETURN pageRank(a via p using weights blah saving state in property x)

:)

But seriously, aren't you alluding to a key distinction here - Graph
Querying vs. Graph Processing?

For processing, cypher is not your friend. But neither is writing jobs from
scratch in your language of choice - at least not compared to writing a
gremlin script.

In this space (processing-style traversals), are there any use cases that
are better served by arbitrary script execution than gremlin queries? And
is catering to those use cases, if they exist, worth the cost in confusion,
diffusion of effort and security problems?


>
> Andrés
> ___
> 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

Re: [Neo4j] REST traverse deprecation

[Andres Taylor]

On Wed, Nov 2, 2011 at 11:56 AM, Jacob Hansson <
jacob.hans...@neotechnology.com> wrote:

> On Wed, Nov 2, 2011 at 11:11 AM, Michael Hunger <
> michael.hun...@neotechnology.com> wrote:
>
> > * custom traversals with complicated callbacks
> >
>
> This is really what my original question to Peter was about - what are some
> traversals like this, that we currently cannot do with Cypher or Gremlin?
> Can we extend Cypher to accomodate those use cases?


Well, Gremlin is just Groovy+Pipes, so there's nothing you can't do in
Gremlin.

If we're talking about Cypher, I have one for you: PageRank. PageRank
iterates over the data set a specified number of times, marking and
updating stuff on the fly, until it's happy and returns a result. It's not
hard at all to write using Gremlin, but impossible with Cypher. I can't see
a way to make that nice and easy with Cypher.

Andrés
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST traverse deprecation

[Jacob Hansson]

On Wed, Nov 2, 2011 at 11:11 AM, Michael Hunger <
michael.hun...@neotechnology.com> wrote:

> custom use-cases like the ones implemented by our customers with plugins /
> extensions
>
> and in the case of the ruby script extensions a way I'd like to promote to
> talk to the server that is
>
> 1) create you own RESTful endpoints that are focused on a protocol
> speaking your domain and not nodes + rels
>

Isn't running domain logic inside a database server a well known
anti-pattern? My experience with companies building lots of stuff with
stored procedures is that it is *really* hard to maintain, hard to scale,
hard to test, hard to tweak and impossible to get an overview of.

See for instance how much pain Etsy.com had getting off this type of
architecture:

http://arstechnica.com/business/news/2011/10/when-clever-goes-wrong-how-etsy-overcame-poor-architectural-choices.ars


> 2) the protocol is use-case oriented
>

This also implies running domain logic in the database server.


> 3) it only transmits the information necessary (not more).
>

This is a really good point. Wouldn't it be better though, if we pulled
some use cases like this out and said "we need Cypher to be able to do
this", and thus make Cypher better, rather than saying "screw it, lets just
let clients use the database as an application server".

What are some use cases where this occurs? Lets look at them, and see if it
would be possible to make cypher or gremlin do it.


> 4) The code of these endpoints would be transactionally executed
>

This is a bug, in my mind, of the REST API. Solving it in roundabout ways
like this and the batch-operations-API is not actually solving the problem.


>
> Use-Cases with customers so far have been:
> * unique nodes with locking + index lookup
>

This is an *excellent* use case. Compared to the scripting solution,
wouldn't it be better if we supported upserts directly in the REST API, as
a core feature?


> * batch data insertion (also unique stuff see above)
>

This is mainly because the REST API is slow, no? If so, spending time
working around the problem with arbitrary script execution is beating
around the bush. We should fix the real problem here, not hack around it.


> * custom traversals with complicated callbacks
>

This is really what my original question to Peter was about - what are some
traversals like this, that we currently cannot do with Cypher or Gremlin?
Can we extend Cypher to accomodate those use cases?


> * aggregating multiple gremlin / cypher queries in the server and
> returning only a partial result-set/projection of those executions
>

This also seems like a limitation of Cypher. Can you give an example of
when this would be necessary, and we can talk about how that could be
integrated into Cypher, if possible?


> * 
>
> With the ruby script extension what we've done there is to leverage the
> web/REST frameworks of the platform and allow rack-apps to expose their
> REST endpoints within the neo4j-server.
>

> Thomas and I also talked about a more generic way to allow any language
> supported by the javax.script extension to register endpoints with the
> neo4j-server.
>
> A generic javax.scripting languages plugin would accommodate for more
> ad-hoc execution mode for which writing an extension is too much ceremony.
>
> Michael
>
>
> Am 02.11.2011 um 10:54 schrieb Jacob Hansson:
>
> > On Wed, Nov 2, 2011 at 10:20 AM, Michael Hunger <
> > michael.hun...@neotechnology.com> wrote:
> >
> >> I vote not dropped, as there are lots of non-java developers out there
> >> which would want to use REST server dynamically.
> >>
> >
> > I am completely open to the notion that I am wrong here. But I want us to
> > have answered the questions I was asking before properly, if we are going
> > to embrace all these ways to talk to the server.
> >
> >
> > What use cases does dynamic script execution cover that cypher or gremlin
> > do not?
> >
> > Why should those use cases not be covered by cypher or gremlin?
> >
> >
> >
> >>
> >> That was the reason why we wrote the ruby-script-extension support.
> >>
> >> Michael
> >>
> >> Am 02.11.2011 um 10:08 schrieb Jacob Hansson:
> >>
> >>> On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
> >>> peter.neuba...@neotechnology.com> wrote:
> >>>
>  Well,
>  I think that Cypher is not yes taking into account Uniqueness, or is
>  it Andres? Otherwise, most of the normal traversals are covered.
> 
>  To keep things consistent and give people a way of doing fine grained
>  traversals, I would then suggest to document all the existing examples
>  using Cypher or Groovy code, so we can document that things are
>  working as expected and not loose functionality.
> 
> >>>
> >>> Sounds like a really good idea.
> >>>
> >>>
> 
>  The JavaScript exposure then would totally go away from the REST API
>  and possibly be factored out into a plugin like Groovy/Gremlin. Or
>  dropped.
> 
> >>>
> >>> I vote dropped :)

Re: [Neo4j] REST traverse deprecation

[Michael Hunger]

custom use-cases like the ones implemented by our customers with plugins / 
extensions

and in the case of the ruby script extensions a way I'd like to promote to talk 
to the server that is

1) create you own RESTful endpoints that are focused on a protocol speaking 
your domain and not nodes + rels
2) the protocol is use-case oriented
3) it only transmits the information necessary (not more). 
4) The code of these endpoints would be transactionally executed

Use-Cases with customers so far have been:
* unique nodes with locking + index lookup
* batch data insertion (also unique stuff see above)
* custom traversals with complicated callbacks
* aggregating multiple gremlin / cypher queries in the server and returning 
only a partial result-set/projection of those executions
* 

With the ruby script extension what we've done there is to leverage the 
web/REST frameworks of the platform and allow rack-apps to expose their REST 
endpoints within the neo4j-server.

Thomas and I also talked about a more generic way to allow any language 
supported by the javax.script extension to register endpoints with the 
neo4j-server.

A generic javax.scripting languages plugin would accommodate for more ad-hoc 
execution mode for which writing an extension is too much ceremony.

Michael


Am 02.11.2011 um 10:54 schrieb Jacob Hansson:

> On Wed, Nov 2, 2011 at 10:20 AM, Michael Hunger <
> michael.hun...@neotechnology.com> wrote:
> 
>> I vote not dropped, as there are lots of non-java developers out there
>> which would want to use REST server dynamically.
>> 
> 
> I am completely open to the notion that I am wrong here. But I want us to
> have answered the questions I was asking before properly, if we are going
> to embrace all these ways to talk to the server.
> 
> 
> What use cases does dynamic script execution cover that cypher or gremlin
> do not?
> 
> Why should those use cases not be covered by cypher or gremlin?
> 
> 
> 
>> 
>> That was the reason why we wrote the ruby-script-extension support.
>> 
>> Michael
>> 
>> Am 02.11.2011 um 10:08 schrieb Jacob Hansson:
>> 
>>> On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
>>> peter.neuba...@neotechnology.com> wrote:
>>> 
 Well,
 I think that Cypher is not yes taking into account Uniqueness, or is
 it Andres? Otherwise, most of the normal traversals are covered.
 
 To keep things consistent and give people a way of doing fine grained
 traversals, I would then suggest to document all the existing examples
 using Cypher or Groovy code, so we can document that things are
 working as expected and not loose functionality.
 
>>> 
>>> Sounds like a really good idea.
>>> 
>>> 
 
 The JavaScript exposure then would totally go away from the REST API
 and possibly be factored out into a plugin like Groovy/Gremlin. Or
 dropped.
 
>>> 
>>> I vote dropped :)
>>> 
>>> 
 
 WDYT?
 
 Cheers,
 
 /peter neubauer
 
 GTalk:  neubauer.peter
 Skype   peter.neubauer
 Phone   +46 704 106975
 LinkedIn   http://www.linkedin.com/in/neubauer
 Twitter  http://twitter.com/peterneubauer
 
 http://www.neo4j.org  - NOSQL for the Enterprise.
 http://startupbootcamp.org/- Öresund - Innovation happens HERE.
 
 
 
 On Tue, Nov 1, 2011 at 9:31 AM, Jacob Hansson
  wrote:
> On Tue, Nov 1, 2011 at 5:22 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
> 
>> Nope,
>> I mean a server side script execution (which we already are doing in
>> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
>> execute traversal API code on the server. Neo4js is a client driver.
>> 
>> 
> Remember that adding yet another way to talk to the server comes at a
 cost
> of confusion and spreading engineering focus thin.
> 
> I don't think we should do this unless there is a good answer to the
> question:
> 
> *Is there anything* *that this solves that is not solved by Cypher or
> Gremlin, and if so, why don't we expand Cypher or Gremlin to
>> incorporate
> that use case instead?
> 
> *Collecting our efforts in fewer buckets means that improvements will
> benefit everyone, not just the group that uses the Groovy endpoint, or
 the
> Traversal API, or the JS endpoint and so on.
> 
> 
>> Cheers,
>> 
>> /peter neubauer
>> 
>> GTalk:  neubauer.peter
>> Skype   peter.neubauer
>> Phone   +46 704 106975
>> LinkedIn   http://www.linkedin.com/in/neubauer
>> Twitter  http://twitter.com/peterneubauer
>> 
>> http://www.neo4j.org  - NOSQL for the Enterprise.
>> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>> 
>> 
>> 
>> On Tue, Nov 1, 2011 at 9:19 AM, Andres Taylor
>>  wrote:
>>> You, something like Neo4js 

Re: [Neo4j] REST traverse deprecation

[Jacob Hansson]

On Wed, Nov 2, 2011 at 10:20 AM, Michael Hunger <
michael.hun...@neotechnology.com> wrote:

> I vote not dropped, as there are lots of non-java developers out there
> which would want to use REST server dynamically.
>

I am completely open to the notion that I am wrong here. But I want us to
have answered the questions I was asking before properly, if we are going
to embrace all these ways to talk to the server.


What use cases does dynamic script execution cover that cypher or gremlin
do not?

Why should those use cases not be covered by cypher or gremlin?



>
> That was the reason why we wrote the ruby-script-extension support.
>
> Michael
>
> Am 02.11.2011 um 10:08 schrieb Jacob Hansson:
>
> > On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
> > peter.neuba...@neotechnology.com> wrote:
> >
> >> Well,
> >> I think that Cypher is not yes taking into account Uniqueness, or is
> >> it Andres? Otherwise, most of the normal traversals are covered.
> >>
> >> To keep things consistent and give people a way of doing fine grained
> >> traversals, I would then suggest to document all the existing examples
> >> using Cypher or Groovy code, so we can document that things are
> >> working as expected and not loose functionality.
> >>
> >
> > Sounds like a really good idea.
> >
> >
> >>
> >> The JavaScript exposure then would totally go away from the REST API
> >> and possibly be factored out into a plugin like Groovy/Gremlin. Or
> >> dropped.
> >>
> >
> > I vote dropped :)
> >
> >
> >>
> >> WDYT?
> >>
> >> Cheers,
> >>
> >> /peter neubauer
> >>
> >> GTalk:  neubauer.peter
> >> Skype   peter.neubauer
> >> Phone   +46 704 106975
> >> LinkedIn   http://www.linkedin.com/in/neubauer
> >> Twitter  http://twitter.com/peterneubauer
> >>
> >> http://www.neo4j.org  - NOSQL for the Enterprise.
> >> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> >>
> >>
> >>
> >> On Tue, Nov 1, 2011 at 9:31 AM, Jacob Hansson
> >>  wrote:
> >>> On Tue, Nov 1, 2011 at 5:22 PM, Peter Neubauer <
> >>> peter.neuba...@neotechnology.com> wrote:
> >>>
>  Nope,
>  I mean a server side script execution (which we already are doing in
>  http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
>  execute traversal API code on the server. Neo4js is a client driver.
> 
> 
> >>> Remember that adding yet another way to talk to the server comes at a
> >> cost
> >>> of confusion and spreading engineering focus thin.
> >>>
> >>> I don't think we should do this unless there is a good answer to the
> >>> question:
> >>>
> >>> *Is there anything* *that this solves that is not solved by Cypher or
> >>> Gremlin, and if so, why don't we expand Cypher or Gremlin to
> incorporate
> >>> that use case instead?
> >>>
> >>> *Collecting our efforts in fewer buckets means that improvements will
> >>> benefit everyone, not just the group that uses the Groovy endpoint, or
> >> the
> >>> Traversal API, or the JS endpoint and so on.
> >>>
> >>>
>  Cheers,
> 
>  /peter neubauer
> 
>  GTalk:  neubauer.peter
>  Skype   peter.neubauer
>  Phone   +46 704 106975
>  LinkedIn   http://www.linkedin.com/in/neubauer
>  Twitter  http://twitter.com/peterneubauer
> 
>  http://www.neo4j.org  - NOSQL for the Enterprise.
>  http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> 
> 
> 
>  On Tue, Nov 1, 2011 at 9:19 AM, Andres Taylor
>   wrote:
> > You, something like Neo4js ? We've
> >> had
> > that since forever. Or do you mean something different?
> >
> > Andrés
> >
> > On Tue, Nov 1, 2011 at 5:06 PM, Peter Neubauer <
> > peter.neuba...@neotechnology.com> wrote:
> >
> >> Also,
> >> there is another possibility: We are exposing a ECMA script
> execution
> >> engine via the Traverse enpoints. Instead of trying to shoehorn the
> >> traversal API into REST calls and then anyway executing script
> >> snippets, Why not exposing a JavaScript plugin along exactly the
> same
> >> lines as the Groovy plugin, and provide examples on how to use the
> >> same usecases via that plugin, so we cover the traversal API that
> >> way?
> >>
> >> Cheers,
> >>
> >> /peter neubauer
> >>
> >> GTalk:  neubauer.peter
> >> Skype   peter.neubauer
> >> Phone   +46 704 106975
> >> LinkedIn   http://www.linkedin.com/in/neubauer
> >> Twitter  http://twitter.com/peterneubauer
> >>
> >> http://www.neo4j.org  - NOSQL for the Enterprise.
> >> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> >>
> >>
> >>
> >> On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
> >>  wrote:
> >>> It would be interesting to rephrase the question like this:
> >>>
> >>> Are there any use cases that the REST traversal API covers, that we
> >

Re: [Neo4j] REST traverse deprecation

[Michael Hunger]

I vote not dropped, as there are lots of non-java developers out there which 
would want to use REST server dynamically. 

That was the reason why we wrote the ruby-script-extension support.

Michael

Am 02.11.2011 um 10:08 schrieb Jacob Hansson:

> On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
> 
>> Well,
>> I think that Cypher is not yes taking into account Uniqueness, or is
>> it Andres? Otherwise, most of the normal traversals are covered.
>> 
>> To keep things consistent and give people a way of doing fine grained
>> traversals, I would then suggest to document all the existing examples
>> using Cypher or Groovy code, so we can document that things are
>> working as expected and not loose functionality.
>> 
> 
> Sounds like a really good idea.
> 
> 
>> 
>> The JavaScript exposure then would totally go away from the REST API
>> and possibly be factored out into a plugin like Groovy/Gremlin. Or
>> dropped.
>> 
> 
> I vote dropped :)
> 
> 
>> 
>> WDYT?
>> 
>> Cheers,
>> 
>> /peter neubauer
>> 
>> GTalk:  neubauer.peter
>> Skype   peter.neubauer
>> Phone   +46 704 106975
>> LinkedIn   http://www.linkedin.com/in/neubauer
>> Twitter  http://twitter.com/peterneubauer
>> 
>> http://www.neo4j.org  - NOSQL for the Enterprise.
>> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>> 
>> 
>> 
>> On Tue, Nov 1, 2011 at 9:31 AM, Jacob Hansson
>>  wrote:
>>> On Tue, Nov 1, 2011 at 5:22 PM, Peter Neubauer <
>>> peter.neuba...@neotechnology.com> wrote:
>>> 
 Nope,
 I mean a server side script execution (which we already are doing in
 http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
 execute traversal API code on the server. Neo4js is a client driver.
 
 
>>> Remember that adding yet another way to talk to the server comes at a
>> cost
>>> of confusion and spreading engineering focus thin.
>>> 
>>> I don't think we should do this unless there is a good answer to the
>>> question:
>>> 
>>> *Is there anything* *that this solves that is not solved by Cypher or
>>> Gremlin, and if so, why don't we expand Cypher or Gremlin to incorporate
>>> that use case instead?
>>> 
>>> *Collecting our efforts in fewer buckets means that improvements will
>>> benefit everyone, not just the group that uses the Groovy endpoint, or
>> the
>>> Traversal API, or the JS endpoint and so on.
>>> 
>>> 
 Cheers,
 
 /peter neubauer
 
 GTalk:  neubauer.peter
 Skype   peter.neubauer
 Phone   +46 704 106975
 LinkedIn   http://www.linkedin.com/in/neubauer
 Twitter  http://twitter.com/peterneubauer
 
 http://www.neo4j.org  - NOSQL for the Enterprise.
 http://startupbootcamp.org/- Öresund - Innovation happens HERE.
 
 
 
 On Tue, Nov 1, 2011 at 9:19 AM, Andres Taylor
  wrote:
> You, something like Neo4js ? We've
>> had
> that since forever. Or do you mean something different?
> 
> Andrés
> 
> On Tue, Nov 1, 2011 at 5:06 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
> 
>> Also,
>> there is another possibility: We are exposing a ECMA script execution
>> engine via the Traverse enpoints. Instead of trying to shoehorn the
>> traversal API into REST calls and then anyway executing script
>> snippets, Why not exposing a JavaScript plugin along exactly the same
>> lines as the Groovy plugin, and provide examples on how to use the
>> same usecases via that plugin, so we cover the traversal API that
>> way?
>> 
>> Cheers,
>> 
>> /peter neubauer
>> 
>> GTalk:  neubauer.peter
>> Skype   peter.neubauer
>> Phone   +46 704 106975
>> LinkedIn   http://www.linkedin.com/in/neubauer
>> Twitter  http://twitter.com/peterneubauer
>> 
>> http://www.neo4j.org  - NOSQL for the Enterprise.
>> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>> 
>> 
>> 
>> On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
>>  wrote:
>>> It would be interesting to rephrase the question like this:
>>> 
>>> Are there any use cases that the REST traversal API covers, that we
>>> currently cannot replicate in Cypher or Gremlin?
>>> 
>>> On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
>>> peter.neuba...@neotechnology.com> wrote:
>>> 
 Well,
 Andres has been putting the first algo into cypher and we are
 thinking
>> of
 exposing them there so thru can be used as path functions in an
>> expression.
 However, that will be step 2. WDYT?
 On Oct 29, 2011 6:47 PM, "maxdemarzi" 
>> wrote:
 
> I think the traversal rest api is fine for my purposes, but if
 cypher
>> is
> where we want to go long term, then we need to deprecate it in
>> 1.6
 

Re: [Neo4j] REST traverse deprecation

[Jacob Hansson]

On Tue, Nov 1, 2011 at 5:37 PM, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:

> Well,
> I think that Cypher is not yes taking into account Uniqueness, or is
> it Andres? Otherwise, most of the normal traversals are covered.
>
> To keep things consistent and give people a way of doing fine grained
> traversals, I would then suggest to document all the existing examples
> using Cypher or Groovy code, so we can document that things are
> working as expected and not loose functionality.
>

Sounds like a really good idea.


>
> The JavaScript exposure then would totally go away from the REST API
> and possibly be factored out into a plugin like Groovy/Gremlin. Or
> dropped.
>

I vote dropped :)


>
> WDYT?
>
> Cheers,
>
> /peter neubauer
>
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
>
> http://www.neo4j.org  - NOSQL for the Enterprise.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>
>
>
> On Tue, Nov 1, 2011 at 9:31 AM, Jacob Hansson
>  wrote:
> > On Tue, Nov 1, 2011 at 5:22 PM, Peter Neubauer <
> > peter.neuba...@neotechnology.com> wrote:
> >
> >> Nope,
> >> I mean a server side script execution (which we already are doing in
> >> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
> >> execute traversal API code on the server. Neo4js is a client driver.
> >>
> >>
> > Remember that adding yet another way to talk to the server comes at a
> cost
> > of confusion and spreading engineering focus thin.
> >
> > I don't think we should do this unless there is a good answer to the
> > question:
> >
> > *Is there anything* *that this solves that is not solved by Cypher or
> > Gremlin, and if so, why don't we expand Cypher or Gremlin to incorporate
> > that use case instead?
> >
> > *Collecting our efforts in fewer buckets means that improvements will
> > benefit everyone, not just the group that uses the Groovy endpoint, or
> the
> > Traversal API, or the JS endpoint and so on.
> >
> >
> >> Cheers,
> >>
> >> /peter neubauer
> >>
> >> GTalk:  neubauer.peter
> >> Skype   peter.neubauer
> >> Phone   +46 704 106975
> >> LinkedIn   http://www.linkedin.com/in/neubauer
> >> Twitter  http://twitter.com/peterneubauer
> >>
> >> http://www.neo4j.org  - NOSQL for the Enterprise.
> >> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> >>
> >>
> >>
> >> On Tue, Nov 1, 2011 at 9:19 AM, Andres Taylor
> >>  wrote:
> >> > You, something like Neo4js ? We've
> had
> >> > that since forever. Or do you mean something different?
> >> >
> >> > Andrés
> >> >
> >> > On Tue, Nov 1, 2011 at 5:06 PM, Peter Neubauer <
> >> > peter.neuba...@neotechnology.com> wrote:
> >> >
> >> >> Also,
> >> >> there is another possibility: We are exposing a ECMA script execution
> >> >> engine via the Traverse enpoints. Instead of trying to shoehorn the
> >> >> traversal API into REST calls and then anyway executing script
> >> >> snippets, Why not exposing a JavaScript plugin along exactly the same
> >> >> lines as the Groovy plugin, and provide examples on how to use the
> >> >> same usecases via that plugin, so we cover the traversal API that
> way?
> >> >>
> >> >> Cheers,
> >> >>
> >> >> /peter neubauer
> >> >>
> >> >> GTalk:  neubauer.peter
> >> >> Skype   peter.neubauer
> >> >> Phone   +46 704 106975
> >> >> LinkedIn   http://www.linkedin.com/in/neubauer
> >> >> Twitter  http://twitter.com/peterneubauer
> >> >>
> >> >> http://www.neo4j.org  - NOSQL for the Enterprise.
> >> >> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
> >> >>  wrote:
> >> >> > It would be interesting to rephrase the question like this:
> >> >> >
> >> >> > Are there any use cases that the REST traversal API covers, that we
> >> >> > currently cannot replicate in Cypher or Gremlin?
> >> >> >
> >> >> > On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
> >> >> > peter.neuba...@neotechnology.com> wrote:
> >> >> >
> >> >> >> Well,
> >> >> >> Andres has been putting the first algo into cypher and we are
> >> thinking
> >> >> of
> >> >> >> exposing them there so thru can be used as path functions in an
> >> >> expression.
> >> >> >> However, that will be step 2. WDYT?
> >> >> >> On Oct 29, 2011 6:47 PM, "maxdemarzi" 
> wrote:
> >> >> >>
> >> >> >> > I think the traversal rest api is fine for my purposes, but if
> >> cypher
> >> >> is
> >> >> >> > where we want to go long term, then we need to deprecate it in
> 1.6
> >> and
> >> >> >> drop
> >> >> >> > it in 1.7.
> >> >> >> >
> >> >> >> > This gives us some time to update our libraries and for cypher
> to
> >> >> settle
> >> >> >> > down.
> >> >> >> >
> >> >> >> > Are you guys thinking of getting rid of the rest built in graph
> >> >> >> algorit

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Well,
I think that Cypher is not yes taking into account Uniqueness, or is
it Andres? Otherwise, most of the normal traversals are covered.

To keep things consistent and give people a way of doing fine grained
traversals, I would then suggest to document all the existing examples
using Cypher or Groovy code, so we can document that things are
working as expected and not loose functionality.

The JavaScript exposure then would totally go away from the REST API
and possibly be factored out into a plugin like Groovy/Gremlin. Or
dropped.

WDYT?

Cheers,

/peter neubauer

GTalk:      neubauer.peter
Skype       peter.neubauer
Phone       +46 704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter      http://twitter.com/peterneubauer

http://www.neo4j.org              - NOSQL for the Enterprise.
http://startupbootcamp.org/    - Öresund - Innovation happens HERE.



On Tue, Nov 1, 2011 at 9:31 AM, Jacob Hansson
 wrote:
> On Tue, Nov 1, 2011 at 5:22 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
>
>> Nope,
>> I mean a server side script execution (which we already are doing in
>> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
>> execute traversal API code on the server. Neo4js is a client driver.
>>
>>
> Remember that adding yet another way to talk to the server comes at a cost
> of confusion and spreading engineering focus thin.
>
> I don't think we should do this unless there is a good answer to the
> question:
>
> *Is there anything* *that this solves that is not solved by Cypher or
> Gremlin, and if so, why don't we expand Cypher or Gremlin to incorporate
> that use case instead?
>
> *Collecting our efforts in fewer buckets means that improvements will
> benefit everyone, not just the group that uses the Groovy endpoint, or the
> Traversal API, or the JS endpoint and so on.
>
>
>> Cheers,
>>
>> /peter neubauer
>>
>> GTalk:      neubauer.peter
>> Skype       peter.neubauer
>> Phone       +46 704 106975
>> LinkedIn   http://www.linkedin.com/in/neubauer
>> Twitter      http://twitter.com/peterneubauer
>>
>> http://www.neo4j.org              - NOSQL for the Enterprise.
>> http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
>>
>>
>>
>> On Tue, Nov 1, 2011 at 9:19 AM, Andres Taylor
>>  wrote:
>> > You, something like Neo4js ? We've had
>> > that since forever. Or do you mean something different?
>> >
>> > Andrés
>> >
>> > On Tue, Nov 1, 2011 at 5:06 PM, Peter Neubauer <
>> > peter.neuba...@neotechnology.com> wrote:
>> >
>> >> Also,
>> >> there is another possibility: We are exposing a ECMA script execution
>> >> engine via the Traverse enpoints. Instead of trying to shoehorn the
>> >> traversal API into REST calls and then anyway executing script
>> >> snippets, Why not exposing a JavaScript plugin along exactly the same
>> >> lines as the Groovy plugin, and provide examples on how to use the
>> >> same usecases via that plugin, so we cover the traversal API that way?
>> >>
>> >> Cheers,
>> >>
>> >> /peter neubauer
>> >>
>> >> GTalk:      neubauer.peter
>> >> Skype       peter.neubauer
>> >> Phone       +46 704 106975
>> >> LinkedIn   http://www.linkedin.com/in/neubauer
>> >> Twitter      http://twitter.com/peterneubauer
>> >>
>> >> http://www.neo4j.org              - NOSQL for the Enterprise.
>> >> http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
>> >>
>> >>
>> >>
>> >> On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
>> >>  wrote:
>> >> > It would be interesting to rephrase the question like this:
>> >> >
>> >> > Are there any use cases that the REST traversal API covers, that we
>> >> > currently cannot replicate in Cypher or Gremlin?
>> >> >
>> >> > On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
>> >> > peter.neuba...@neotechnology.com> wrote:
>> >> >
>> >> >> Well,
>> >> >> Andres has been putting the first algo into cypher and we are
>> thinking
>> >> of
>> >> >> exposing them there so thru can be used as path functions in an
>> >> expression.
>> >> >> However, that will be step 2. WDYT?
>> >> >> On Oct 29, 2011 6:47 PM, "maxdemarzi"  wrote:
>> >> >>
>> >> >> > I think the traversal rest api is fine for my purposes, but if
>> cypher
>> >> is
>> >> >> > where we want to go long term, then we need to deprecate it in 1.6
>> and
>> >> >> drop
>> >> >> > it in 1.7.
>> >> >> >
>> >> >> > This gives us some time to update our libraries and for cypher to
>> >> settle
>> >> >> > down.
>> >> >> >
>> >> >> > Are you guys thinking of getting rid of the rest built in graph
>> >> >> algorithms
>> >> >> > or are those there to stay?
>> >> >> >
>> >> >> > --
>> >> >> > View this message in context:
>> >> >> >
>> >> >>
>> >>
>> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
>> >> >> > Sent from the Neo4j Community Discussions mailing list archive at
>> >> >> > Nabble.com.
>> >> >> > ___
>> >> >> > Neo4j mail

Re: [Neo4j] REST traverse deprecation

[Jacob Hansson]

On Tue, Nov 1, 2011 at 5:22 PM, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:

> Nope,
> I mean a server side script execution (which we already are doing in
> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
> execute traversal API code on the server. Neo4js is a client driver.
>
>
Remember that adding yet another way to talk to the server comes at a cost
of confusion and spreading engineering focus thin.

I don't think we should do this unless there is a good answer to the
question:

*Is there anything* *that this solves that is not solved by Cypher or
Gremlin, and if so, why don't we expand Cypher or Gremlin to incorporate
that use case instead?

*Collecting our efforts in fewer buckets means that improvements will
benefit everyone, not just the group that uses the Groovy endpoint, or the
Traversal API, or the JS endpoint and so on.


> Cheers,
>
> /peter neubauer
>
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
>
> http://www.neo4j.org  - NOSQL for the Enterprise.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>
>
>
> On Tue, Nov 1, 2011 at 9:19 AM, Andres Taylor
>  wrote:
> > You, something like Neo4js ? We've had
> > that since forever. Or do you mean something different?
> >
> > Andrés
> >
> > On Tue, Nov 1, 2011 at 5:06 PM, Peter Neubauer <
> > peter.neuba...@neotechnology.com> wrote:
> >
> >> Also,
> >> there is another possibility: We are exposing a ECMA script execution
> >> engine via the Traverse enpoints. Instead of trying to shoehorn the
> >> traversal API into REST calls and then anyway executing script
> >> snippets, Why not exposing a JavaScript plugin along exactly the same
> >> lines as the Groovy plugin, and provide examples on how to use the
> >> same usecases via that plugin, so we cover the traversal API that way?
> >>
> >> Cheers,
> >>
> >> /peter neubauer
> >>
> >> GTalk:  neubauer.peter
> >> Skype   peter.neubauer
> >> Phone   +46 704 106975
> >> LinkedIn   http://www.linkedin.com/in/neubauer
> >> Twitter  http://twitter.com/peterneubauer
> >>
> >> http://www.neo4j.org  - NOSQL for the Enterprise.
> >> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> >>
> >>
> >>
> >> On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
> >>  wrote:
> >> > It would be interesting to rephrase the question like this:
> >> >
> >> > Are there any use cases that the REST traversal API covers, that we
> >> > currently cannot replicate in Cypher or Gremlin?
> >> >
> >> > On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
> >> > peter.neuba...@neotechnology.com> wrote:
> >> >
> >> >> Well,
> >> >> Andres has been putting the first algo into cypher and we are
> thinking
> >> of
> >> >> exposing them there so thru can be used as path functions in an
> >> expression.
> >> >> However, that will be step 2. WDYT?
> >> >> On Oct 29, 2011 6:47 PM, "maxdemarzi"  wrote:
> >> >>
> >> >> > I think the traversal rest api is fine for my purposes, but if
> cypher
> >> is
> >> >> > where we want to go long term, then we need to deprecate it in 1.6
> and
> >> >> drop
> >> >> > it in 1.7.
> >> >> >
> >> >> > This gives us some time to update our libraries and for cypher to
> >> settle
> >> >> > down.
> >> >> >
> >> >> > Are you guys thinking of getting rid of the rest built in graph
> >> >> algorithms
> >> >> > or are those there to stay?
> >> >> >
> >> >> > --
> >> >> > View this message in context:
> >> >> >
> >> >>
> >>
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
> >> >> > Sent from the Neo4j Community Discussions mailing list archive at
> >> >> > Nabble.com.
> >> >> > ___
> >> >> > 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
> >>
> > ___
> > 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
Twit

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Nope,
I mean a server side script execution (which we already are doing in
http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html) to
execute traversal API code on the server. Neo4js is a client driver.

Cheers,

/peter neubauer

GTalk:      neubauer.peter
Skype       peter.neubauer
Phone       +46 704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter      http://twitter.com/peterneubauer

http://www.neo4j.org              - NOSQL for the Enterprise.
http://startupbootcamp.org/    - Öresund - Innovation happens HERE.



On Tue, Nov 1, 2011 at 9:19 AM, Andres Taylor
 wrote:
> You, something like Neo4js ? We've had
> that since forever. Or do you mean something different?
>
> Andrés
>
> On Tue, Nov 1, 2011 at 5:06 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
>
>> Also,
>> there is another possibility: We are exposing a ECMA script execution
>> engine via the Traverse enpoints. Instead of trying to shoehorn the
>> traversal API into REST calls and then anyway executing script
>> snippets, Why not exposing a JavaScript plugin along exactly the same
>> lines as the Groovy plugin, and provide examples on how to use the
>> same usecases via that plugin, so we cover the traversal API that way?
>>
>> Cheers,
>>
>> /peter neubauer
>>
>> GTalk:      neubauer.peter
>> Skype       peter.neubauer
>> Phone       +46 704 106975
>> LinkedIn   http://www.linkedin.com/in/neubauer
>> Twitter      http://twitter.com/peterneubauer
>>
>> http://www.neo4j.org              - NOSQL for the Enterprise.
>> http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
>>
>>
>>
>> On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
>>  wrote:
>> > It would be interesting to rephrase the question like this:
>> >
>> > Are there any use cases that the REST traversal API covers, that we
>> > currently cannot replicate in Cypher or Gremlin?
>> >
>> > On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
>> > peter.neuba...@neotechnology.com> wrote:
>> >
>> >> Well,
>> >> Andres has been putting the first algo into cypher and we are thinking
>> of
>> >> exposing them there so thru can be used as path functions in an
>> expression.
>> >> However, that will be step 2. WDYT?
>> >> On Oct 29, 2011 6:47 PM, "maxdemarzi"  wrote:
>> >>
>> >> > I think the traversal rest api is fine for my purposes, but if cypher
>> is
>> >> > where we want to go long term, then we need to deprecate it in 1.6 and
>> >> drop
>> >> > it in 1.7.
>> >> >
>> >> > This gives us some time to update our libraries and for cypher to
>> settle
>> >> > down.
>> >> >
>> >> > Are you guys thinking of getting rid of the rest built in graph
>> >> algorithms
>> >> > or are those there to stay?
>> >> >
>> >> > --
>> >> > View this message in context:
>> >> >
>> >>
>> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
>> >> > Sent from the Neo4j Community Discussions mailing list archive at
>> >> > Nabble.com.
>> >> > ___
>> >> > 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
>>
> ___
> 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

Re: [Neo4j] REST traverse deprecation

[Andres Taylor]

You, something like Neo4js ? We've had
that since forever. Or do you mean something different?

Andrés

On Tue, Nov 1, 2011 at 5:06 PM, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:

> Also,
> there is another possibility: We are exposing a ECMA script execution
> engine via the Traverse enpoints. Instead of trying to shoehorn the
> traversal API into REST calls and then anyway executing script
> snippets, Why not exposing a JavaScript plugin along exactly the same
> lines as the Groovy plugin, and provide examples on how to use the
> same usecases via that plugin, so we cover the traversal API that way?
>
> Cheers,
>
> /peter neubauer
>
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
>
> http://www.neo4j.org  - NOSQL for the Enterprise.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>
>
>
> On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
>  wrote:
> > It would be interesting to rephrase the question like this:
> >
> > Are there any use cases that the REST traversal API covers, that we
> > currently cannot replicate in Cypher or Gremlin?
> >
> > On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
> > peter.neuba...@neotechnology.com> wrote:
> >
> >> Well,
> >> Andres has been putting the first algo into cypher and we are thinking
> of
> >> exposing them there so thru can be used as path functions in an
> expression.
> >> However, that will be step 2. WDYT?
> >> On Oct 29, 2011 6:47 PM, "maxdemarzi"  wrote:
> >>
> >> > I think the traversal rest api is fine for my purposes, but if cypher
> is
> >> > where we want to go long term, then we need to deprecate it in 1.6 and
> >> drop
> >> > it in 1.7.
> >> >
> >> > This gives us some time to update our libraries and for cypher to
> settle
> >> > down.
> >> >
> >> > Are you guys thinking of getting rid of the rest built in graph
> >> algorithms
> >> > or are those there to stay?
> >> >
> >> > --
> >> > View this message in context:
> >> >
> >>
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
> >> > Sent from the Neo4j Community Discussions mailing list archive at
> >> > Nabble.com.
> >> > ___
> >> > 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
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Also,
there is another possibility: We are exposing a ECMA script execution
engine via the Traverse enpoints. Instead of trying to shoehorn the
traversal API into REST calls and then anyway executing script
snippets, Why not exposing a JavaScript plugin along exactly the same
lines as the Groovy plugin, and provide examples on how to use the
same usecases via that plugin, so we cover the traversal API that way?

Cheers,

/peter neubauer

GTalk:      neubauer.peter
Skype       peter.neubauer
Phone       +46 704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter      http://twitter.com/peterneubauer

http://www.neo4j.org              - NOSQL for the Enterprise.
http://startupbootcamp.org/    - Öresund - Innovation happens HERE.



On Tue, Nov 1, 2011 at 9:00 AM, Jacob Hansson
 wrote:
> It would be interesting to rephrase the question like this:
>
> Are there any use cases that the REST traversal API covers, that we
> currently cannot replicate in Cypher or Gremlin?
>
> On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
>
>> Well,
>> Andres has been putting the first algo into cypher and we are thinking of
>> exposing them there so thru can be used as path functions in an expression.
>> However, that will be step 2. WDYT?
>> On Oct 29, 2011 6:47 PM, "maxdemarzi"  wrote:
>>
>> > I think the traversal rest api is fine for my purposes, but if cypher is
>> > where we want to go long term, then we need to deprecate it in 1.6 and
>> drop
>> > it in 1.7.
>> >
>> > This gives us some time to update our libraries and for cypher to settle
>> > down.
>> >
>> > Are you guys thinking of getting rid of the rest built in graph
>> algorithms
>> > or are those there to stay?
>> >
>> > --
>> > View this message in context:
>> >
>> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
>> > Sent from the Neo4j Community Discussions mailing list archive at
>> > Nabble.com.
>> > ___
>> > 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

Re: [Neo4j] REST traverse deprecation

[Jacob Hansson]

It would be interesting to rephrase the question like this:

Are there any use cases that the REST traversal API covers, that we
currently cannot replicate in Cypher or Gremlin?

On Sun, Oct 30, 2011 at 2:45 PM, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:

> Well,
> Andres has been putting the first algo into cypher and we are thinking of
> exposing them there so thru can be used as path functions in an expression.
> However, that will be step 2. WDYT?
> On Oct 29, 2011 6:47 PM, "maxdemarzi"  wrote:
>
> > I think the traversal rest api is fine for my purposes, but if cypher is
> > where we want to go long term, then we need to deprecate it in 1.6 and
> drop
> > it in 1.7.
> >
> > This gives us some time to update our libraries and for cypher to settle
> > down.
> >
> > Are you guys thinking of getting rid of the rest built in graph
> algorithms
> > or are those there to stay?
> >
> > --
> > View this message in context:
> >
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
> > Sent from the Neo4j Community Discussions mailing list archive at
> > Nabble.com.
> > ___
> > 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

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Well,
Andres has been putting the first algo into cypher and we are thinking of
exposing them there so thru can be used as path functions in an expression.
However, that will be step 2. WDYT?
On Oct 29, 2011 6:47 PM, "maxdemarzi"  wrote:

> I think the traversal rest api is fine for my purposes, but if cypher is
> where we want to go long term, then we need to deprecate it in 1.6 and drop
> it in 1.7.
>
> This gives us some time to update our libraries and for cypher to settle
> down.
>
> Are you guys thinking of getting rid of the rest built in graph algorithms
> or are those there to stay?
>
> --
> View this message in context:
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
> Sent from the Neo4j Community Discussions mailing list archive at
> Nabble.com.
> ___
> 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

Re: [Neo4j] REST traverse deprecation

[maxdemarzi]

I think the traversal rest api is fine for my purposes, but if cypher is
where we want to go long term, then we need to deprecate it in 1.6 and drop
it in 1.7.

This gives us some time to update our libraries and for cypher to settle
down.

Are you guys thinking of getting rid of the rest built in graph algorithms
or are those there to stay?

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3464979.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Thank you Max! The AREL for Cypher sounds very interesting!

Do you think the traversal rest api us doing its job for you given the power
of hhe häva version? I can even think if having a query method on the
embedded api so it fits...
On Oct 29, 2011 12:19 AM, "maxdemarzi"  wrote:

> This change will kill "phase 2" (the part that tries to mimic the Neo4j.rb
> API) of Neography since I use it to provide idiomatic access to neo4j.
>
> For example:
> def suggestions_for(node)
>  node.incoming(:friends).order("breadth first").uniqueness("node
> global").filter("position.length() == 2;").depth(2)
> end
>
> The options are:
> 1. Have users enter cypher directly ex. node.cypher("some cypher query
> here")
> 2. Create an AREL for Cypher.  ( https://github.com/rails/arel )If it's
> the
> right thing for Neo4j then do what you have to do.
>
> --
> View this message in context:
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3462201.html
> Sent from the Neo4j Community Discussions mailing list archive at
> Nabble.com.
> ___
> 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

Re: [Neo4j] REST traverse deprecation

[maxdemarzi]

This change will kill "phase 2" (the part that tries to mimic the Neo4j.rb
API) of Neography since I use it to provide idiomatic access to neo4j.

For example:
def suggestions_for(node)  
  node.incoming(:friends).order("breadth first").uniqueness("node
global").filter("position.length() == 2;").depth(2)
end

The options are:
1. Have users enter cypher directly ex. node.cypher("some cypher query
here")
2. Create an AREL for Cypher.  ( https://github.com/rails/arel )If it's the
right thing for Neo4j then do what you have to do.

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-REST-traverse-deprecation-tp3460396p3462201.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST traverse deprecation

[Rick Bullotta]

...but maybe offer different "install bundles".

The other danger of forcing them into the server distro is that it increases 
the likelihood of dependency conflicts.  

-Original Message-
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On 
Behalf Of Rick Bullotta
Sent: Friday, October 28, 2011 7:16 AM
To: Neo4j user discussions
Subject: Re: [Neo4j] REST traverse deprecation

"Don't Bloat".

This also allows the plug-ins and language bindings to evolve at a difference 
pace/cycle than the server.  I'd say keep them separate.

-Original Message-
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On 
Behalf Of Jim Webber
Sent: Friday, October 28, 2011 7:11 AM
To: Neo4j user discussions
Subject: Re: [Neo4j] REST traverse deprecation

> If we do that, I propose that we move the Cypher and Gremlin plugins into
> server. WDYT?

I'm ambivalent about that. What end-user benefits are there versus shipping 
them as plugins?

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
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST traverse deprecation

[Rick Bullotta]

"Don't Bloat".

This also allows the plug-ins and language bindings to evolve at a difference 
pace/cycle than the server.  I'd say keep them separate.

-Original Message-
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On 
Behalf Of Jim Webber
Sent: Friday, October 28, 2011 7:11 AM
To: Neo4j user discussions
Subject: Re: [Neo4j] REST traverse deprecation

> If we do that, I propose that we move the Cypher and Gremlin plugins into
> server. WDYT?

I'm ambivalent about that. What end-user benefits are there versus shipping 
them as plugins?

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

Re: [Neo4j] REST traverse deprecation

[Jim Webber]

> If we do that, I propose that we move the Cypher and Gremlin plugins into
> server. WDYT?

I'm ambivalent about that. What end-user benefits are there versus shipping 
them as plugins?

Jim

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST traverse deprecation

[Peter Neubauer]

Also,
If we do that, I propose that we move the Cypher and Gremlin plugins into
server. WDYT?
On Oct 28, 2011 12:03 PM, "Jim Webber"  wrote:

> From the high church of REST, I have no objections.
>
> "Blessed be the Roy, for he hath delivered us from RPC." Or something.
>
> 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

Re: [Neo4j] REST traverse deprecation

[Jim Webber]

>From the high church of REST, I have no objections.

"Blessed be the Roy, for he hath delivered us from RPC." Or something.

Jim
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST traverse deprecation

[Mattias Persson]

I think it's probably a good thing to deprecate it because:

a) it's inferior to native traversals
b) cypher and gremlin does these things much better

2011/10/28 Peter Neubauer 

> Hi all,
> I think that the whole concept of
> http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html is
> broken, since it tries to emulate the embedded traversal logic in
> REST, which is just broken.
>
> With Cypher and Gremlin being MUCH better suited to do declarative and
> scripted traversals, I think it is time to deprecate this part of the
> REST API.
>
> Is anyone going to be very sad if I go ahead and do that?
>
> Cheers,
>
> /peter neubauer
>
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
>
> http://www.neo4j.org  - NOSQL for the Enterprise.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> ___
> 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