[Neo] Neo4j + REST + .NET anyone?

2010-04-07 Thread Tobias Ivarsson
Hi everyone!

With the REST API approaching a usable state it would be great to get some
clients written for it. Since I'll be presenting Neo4j at a .Net conference
next week ( http://mow2010.dk/all-abstracts/tobias-ivarsson.aspx ) it would
be great if there was a .Net client available for me to show. An early
prototype would be enough, but I neither have the time, nor the .Net skills
to implement it. Since this list is full of talented developers I thought
I'd ask for some help. To make things more interesting I'll throw in a Neo4j
t-shirt as a reward for the first .Net Neo4j REST client library with
an accompanying small demo application.

For reference see the documentation of the Neo4j REST API:
 * http://components.neo4j.org/neo4j-rest/
 * http://wiki.neo4j.org/content/Getting_Started_REST

WFC might be a good foundation to build the client library on:
 * http://damianm.com/tech/building-a-rest-client-with-wcf/

Happy hacking!
-- 
Tobias Ivarsson tobias.ivars...@neotechnology.com
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo] Neo4j + REST + .NET anyone?

2010-04-07 Thread Rick Bullotta
Hi, Tobias.

It could be a fairly challenging task to do a general purpose .NET client
using WCF, largely due to the flexibility of the return types (schema-less
and type-less) from the REST API and some challenges that the
DataContractJsonSerializer has in these scenarios.  I think ultimately
there's going to be a need for some type of metamodel built in so that
inbound and outbound requests can properly map in and out of .NET domain
models, but that's probably a bigger effort.  There may be some other
general purpose .NET client JSON parsers that would be easier to work with
and more flexible (e.g. the JSON.NET project).

One suggestion might be to add a DELETE method symmetric with the various
get relationships on node methods.  For example, DELETE
/node/XXX/relationships/all would delete all relationships for node XXX.
This helps make deletion of a node a simpler and more atomic operation.
Also, I think the documentation in the Wiki for get relationships on node
is incorrect since it shows a collection of nodes being returned.  Lastly, I
think it would be very valuable if the relationship type was returned from
the REST API whenever a relationship or collection of relationships is
returned.

Along a related topic, has anyone started a .NET port of Neo4J yet
(Neo4Net)?

Cheers,

Rick

-Original Message-
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On
Behalf Of Tobias Ivarsson
Sent: Wednesday, April 07, 2010 10:37 AM
To: Neo user discussions
Subject: [Neo] Neo4j + REST + .NET anyone?

Hi everyone!

With the REST API approaching a usable state it would be great to get some
clients written for it. Since I'll be presenting Neo4j at a .Net conference
next week ( http://mow2010.dk/all-abstracts/tobias-ivarsson.aspx ) it would
be great if there was a .Net client available for me to show. An early
prototype would be enough, but I neither have the time, nor the .Net skills
to implement it. Since this list is full of talented developers I thought
I'd ask for some help. To make things more interesting I'll throw in a Neo4j
t-shirt as a reward for the first .Net Neo4j REST client library with
an accompanying small demo application.

For reference see the documentation of the Neo4j REST API:
 * http://components.neo4j.org/neo4j-rest/
 * http://wiki.neo4j.org/content/Getting_Started_REST

WFC might be a good foundation to build the client library on:
 * http://damianm.com/tech/building-a-rest-client-with-wcf/

Happy hacking!
-- 
Tobias Ivarsson tobias.ivars...@neotechnology.com
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

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


Re: [Neo] neo4j on .NET

2009-07-02 Thread Antonello Provenzano
Johan,

Thank you for the nice news (and sorry for the late response: I've
been on holidays and when came back I found loads of stuff to
accomplish): I will dig out soon and come back to you...

Cheers.
Antonello


On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com wrote:
 Antonello,

 Just thought I'd mention that trunk now has support for non memory
 mapped buffers. When starting Neo4j just pass in:

 use_memory_mapped_buffers=false

 as a parameter to the public EmbeddedNeo( String storeDir,
 MapString,String params ) constructor.

 The code of plain buffer/direct buffer ports of previously memory
 mapped ones are:

 org.neo4j.impl.nioneo.store.PlainPersistenceWindow
 org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer

 Regards,
 Johan

 On Tue, May 5, 2009 at 8:22 PM, Johan Svensson jo...@neotechnology.com 
 wrote:
 Next release of Neo4j (b9) will have an option not to use memory
 mapped buffers but instead either use direct buffers or normal Java
 buffers. A .NET port could replace the
 org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different
 implementation that does not use the MappedByteBuffer (b9 will soon
 have such an implementation).

 In the transaction package any usage of MappedByteBuffer can be
 replaced with a direct or normal buffer also (they all just append
 data to some file).

 Hopefully I will get my test code of the new persistence windows into
 trunk soon. Once that is done a .NET port could make use of that and
 replace all other usages of memory mapped I/O with normal buffers.

 Regards,
 Johan

 On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano
 antone...@deveel.com wrote:
 I dug a bit the NIO package and the use done in neo4j: unfortunately
 there's not counter part for it on .NET nor the possibility to
 recreate [easily] classes to support it. In fact, you make a wide and
 important use of MappedByteBuffer on files: although implement the
 logics of a ByteBuffer class is not difficult (in .NET schema is the
 association of two classes: MemoryStream and
 BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears
 to be more complex, since access to portion of data in file which
 access must be coordinated with the memory, and this is not a simple
 issue.

 As of Java implementation, this is done natively and it's a complex
 operation to replicate the same functionality.

 Once this is solved, I see no further [major] obstacles to the port:
 avoiding the integration with the System.Transactions mechanism, the
 base of neo4j port would work in its core functionalities.

 Cheers.
 Antonello

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

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


Re: [Neo] neo4j on .NET

2009-07-02 Thread Antonello Provenzano
Johan,

I checked out the latest sources from the SVN server of Neo and I
haven't found the entry point you told me about (EmbeddedNeo
constructor with use_memory_mapped_buffers parameter): can you
clarify me if this can be found in some branch of the project or if
isn't yet committed?

Thank you!
Antonello


On Thu, Jul 2, 2009 at 3:09 PM, Antonello
Provenzanoantone...@deveel.com wrote:
 Johan,

 Thank you for the nice news (and sorry for the late response: I've
 been on holidays and when came back I found loads of stuff to
 accomplish): I will dig out soon and come back to you...

 Cheers.
 Antonello


 On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com wrote:
 Antonello,

 Just thought I'd mention that trunk now has support for non memory
 mapped buffers. When starting Neo4j just pass in:

 use_memory_mapped_buffers=false

 as a parameter to the public EmbeddedNeo( String storeDir,
 MapString,String params ) constructor.

 The code of plain buffer/direct buffer ports of previously memory
 mapped ones are:

 org.neo4j.impl.nioneo.store.PlainPersistenceWindow
 org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer

 Regards,
 Johan

 On Tue, May 5, 2009 at 8:22 PM, Johan Svensson jo...@neotechnology.com 
 wrote:
 Next release of Neo4j (b9) will have an option not to use memory
 mapped buffers but instead either use direct buffers or normal Java
 buffers. A .NET port could replace the
 org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different
 implementation that does not use the MappedByteBuffer (b9 will soon
 have such an implementation).

 In the transaction package any usage of MappedByteBuffer can be
 replaced with a direct or normal buffer also (they all just append
 data to some file).

 Hopefully I will get my test code of the new persistence windows into
 trunk soon. Once that is done a .NET port could make use of that and
 replace all other usages of memory mapped I/O with normal buffers.

 Regards,
 Johan

 On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano
 antone...@deveel.com wrote:
 I dug a bit the NIO package and the use done in neo4j: unfortunately
 there's not counter part for it on .NET nor the possibility to
 recreate [easily] classes to support it. In fact, you make a wide and
 important use of MappedByteBuffer on files: although implement the
 logics of a ByteBuffer class is not difficult (in .NET schema is the
 association of two classes: MemoryStream and
 BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears
 to be more complex, since access to portion of data in file which
 access must be coordinated with the memory, and this is not a simple
 issue.

 As of Java implementation, this is done natively and it's a complex
 operation to replicate the same functionality.

 Once this is solved, I see no further [major] obstacles to the port:
 avoiding the integration with the System.Transactions mechanism, the
 base of neo4j port would work in its core functionalities.

 Cheers.
 Antonello

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


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


Re: [Neo] neo4j on .NET

2009-07-02 Thread Ajay Sharma
i dnt knw whether its related to the topic or not
but am working on creating restful web service using jersey and then
planning to implement and consume these service through .NET WCF.(WSE seems
good option to me)
or using silverlight's webservice support.

please let me know what you guys think about this approach.

suggestions are more then welcome.

Thanks
Ajay


On Thu, Jul 2, 2009 at 8:54 PM, Antonello Provenzano
antone...@deveel.comwrote:

 Johan,

 I checked out the latest sources from the SVN server of Neo and I
 haven't found the entry point you told me about (EmbeddedNeo
 constructor with use_memory_mapped_buffers parameter): can you
 clarify me if this can be found in some branch of the project or if
 isn't yet committed?

 Thank you!
 Antonello


 On Thu, Jul 2, 2009 at 3:09 PM, Antonello
 Provenzanoantone...@deveel.com wrote:
  Johan,
 
  Thank you for the nice news (and sorry for the late response: I've
  been on holidays and when came back I found loads of stuff to
  accomplish): I will dig out soon and come back to you...
 
  Cheers.
  Antonello
 
 
  On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com
 wrote:
  Antonello,
 
  Just thought I'd mention that trunk now has support for non memory
  mapped buffers. When starting Neo4j just pass in:
 
  use_memory_mapped_buffers=false
 
  as a parameter to the public EmbeddedNeo( String storeDir,
  MapString,String params ) constructor.
 
  The code of plain buffer/direct buffer ports of previously memory
  mapped ones are:
 
  org.neo4j.impl.nioneo.store.PlainPersistenceWindow
  org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer
 
  Regards,
  Johan
 
  On Tue, May 5, 2009 at 8:22 PM, Johan Svensson jo...@neotechnology.com
 wrote:
  Next release of Neo4j (b9) will have an option not to use memory
  mapped buffers but instead either use direct buffers or normal Java
  buffers. A .NET port could replace the
  org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different
  implementation that does not use the MappedByteBuffer (b9 will soon
  have such an implementation).
 
  In the transaction package any usage of MappedByteBuffer can be
  replaced with a direct or normal buffer also (they all just append
  data to some file).
 
  Hopefully I will get my test code of the new persistence windows into
  trunk soon. Once that is done a .NET port could make use of that and
  replace all other usages of memory mapped I/O with normal buffers.
 
  Regards,
  Johan
 
  On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano
  antone...@deveel.com wrote:
  I dug a bit the NIO package and the use done in neo4j: unfortunately
  there's not counter part for it on .NET nor the possibility to
  recreate [easily] classes to support it. In fact, you make a wide and
  important use of MappedByteBuffer on files: although implement the
  logics of a ByteBuffer class is not difficult (in .NET schema is the
  association of two classes: MemoryStream and
  BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears
  to be more complex, since access to portion of data in file which
  access must be coordinated with the memory, and this is not a simple
  issue.
 
  As of Java implementation, this is done natively and it's a complex
  operation to replicate the same functionality.
 
  Once this is solved, I see no further [major] obstacles to the port:
  avoiding the integration with the System.Transactions mechanism, the
  base of neo4j port would work in its core functionalities.
 
  Cheers.
  Antonello
 
  ___
  Neo mailing list
  User@lists.neo4j.org
  https://lists.neo4j.org/mailman/listinfo/user
 
 
 ___
 Neo mailing list
 User@lists.neo4j.org
 https://lists.neo4j.org/mailman/listinfo/user




-- 
Ajay Sharma
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo] neo4j on .NET

2009-07-02 Thread Johan Svensson
Antonello,

Pass it in as a key/value pair in the constructor that takes a
configuration map:

   MapString,String params = new HashMapString,String();
   params.put( use_memory_mapped_buffers, false );

   NeoService neo = new EmbeddedNeo( neo-db, params );

Hope that helps.

Regards,
-Johan

On Thu, Jul 2, 2009 at 5:24 PM, Antonello
Provenzanoantone...@deveel.com wrote:
 Johan,

 I checked out the latest sources from the SVN server of Neo and I
 haven't found the entry point you told me about (EmbeddedNeo
 constructor with use_memory_mapped_buffers parameter): can you
 clarify me if this can be found in some branch of the project or if
 isn't yet committed?

 Thank you!
 Antonello


 On Thu, Jul 2, 2009 at 3:09 PM, Antonello
 Provenzanoantone...@deveel.com wrote:
 Johan,

 Thank you for the nice news (and sorry for the late response: I've
 been on holidays and when came back I found loads of stuff to
 accomplish): I will dig out soon and come back to you...

 Cheers.
 Antonello


 On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com 
 wrote:
 Antonello,

 Just thought I'd mention that trunk now has support for non memory
 mapped buffers. When starting Neo4j just pass in:

 use_memory_mapped_buffers=false

 as a parameter to the public EmbeddedNeo( String storeDir,
 MapString,String params ) constructor.

 The code of plain buffer/direct buffer ports of previously memory
 mapped ones are:

 org.neo4j.impl.nioneo.store.PlainPersistenceWindow
 org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer

 Regards,
 Johan
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo] neo4j on .NET

2009-05-05 Thread Johan Svensson
Next release of Neo4j (b9) will have an option not to use memory
mapped buffers but instead either use direct buffers or normal Java
buffers. A .NET port could replace the
org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different
implementation that does not use the MappedByteBuffer (b9 will soon
have such an implementation).

In the transaction package any usage of MappedByteBuffer can be
replaced with a direct or normal buffer also (they all just append
data to some file).

Hopefully I will get my test code of the new persistence windows into
trunk soon. Once that is done a .NET port could make use of that and
replace all other usages of memory mapped I/O with normal buffers.

Regards,
Johan

On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano
antone...@deveel.com wrote:
 I dug a bit the NIO package and the use done in neo4j: unfortunately
 there's not counter part for it on .NET nor the possibility to
 recreate [easily] classes to support it. In fact, you make a wide and
 important use of MappedByteBuffer on files: although implement the
 logics of a ByteBuffer class is not difficult (in .NET schema is the
 association of two classes: MemoryStream and
 BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears
 to be more complex, since access to portion of data in file which
 access must be coordinated with the memory, and this is not a simple
 issue.

 As of Java implementation, this is done natively and it's a complex
 operation to replicate the same functionality.

 Once this is solved, I see no further [major] obstacles to the port:
 avoiding the integration with the System.Transactions mechanism, the
 base of neo4j port would work in its core functionalities.

 Cheers.
 Antonello


 On Sun, May 3, 2009 at 4:51 PM, Johan Svensson jo...@neotechnology.com 
 wrote:
 See my comments inline:

 On Sun, May 3, 2009 at 4:05 PM, Antonello Provenzano
 antone...@deveel.com wrote:
 Johan,

 I see. My knowledge of NIO is pretty limited indeed: since you're
 telling me it's re-designable with traditional java.io
 implementations, I see no particular issues on that side (also
 because, as you described some of the core functionalities, many
 features are already present in System.IO). In fact, what i did know
 was that NIO was used to stream remotely, opening communication
 channels between the local JVM and the remote endpoint (which could
 have been another running application in the same JVM).


 Yes, but we only use the native I/O part for files. Simply put, we
 want to avoid the extra copy of buffers that takes place from outside
 jvm memory to jvm buffers. NIO allows us to allocation direct buffers
 (that are allocated and managed outside the normal java heap). I also
 like the design of the nio package with channels and it is good that
 you can use the same interfaces to shuffle data over the network but
 Neo does not use those features (yet).

 Coming back to Transactions: it's true that JTA is just a set of
 specifications abstracted by the interfaces provided (which are easily
 convertible into .NET with a custom JTA packaging), but it's also true
 that .NET provides a framework for handling application transactions
 in the same fashion as JTA.
 In fact, when a developer instantiate a TransactionScope class, opens
 a transactional context for th execution of the calls withing that
 instance: to support this the JTA support present in neo4j should be
 adapted to the specifications provided by System.Transactions, which
 don't support XA nor 2PC (heavily used by neo4j).


 It should be possible to port Neo4j's transaction handling to support
 .NET's way of handling transactions. Neo will only make use of 2PC if
 there are multiple resources participating in the transaction. If you
 only use Neo and nothing else all commits will be optimized one phase
 commits.

 How would .NET handle a transaction that would like to modify
 something in two different databases in the same transactional
 context? That is what we use the two phase commit protocol for but if
 you only use Neo4j there is only one resources enlisted in the
 transaction so then it is not needed.

 It's true that it would be possible to create a custom transaction
 namespace within the ported neo4j, but this would change the behavior
 of the application: I don't know for sure, but JTA interacts with
 underlying systems for the management of transactions, as
 System.Transaction does; having a custom transaction mechanism would
 bypass all this.


 Yes, also it might be possible to just write some glue code between
 the .NET TransactionScope and the NeoService.beginTx() 
 org.neo4j.api.core.Transaction classes. If all you need is single
 resource, begin,commit and rollback it would be much easier to
 integrate there and just do a straightforward port of the transaction
 package.

 Regards,
 Johan

 Cheers.
 Antonello
___
Neo mailing list
User@lists.neo4j.org

Re: [Neo] neo4j on .NET

2009-05-05 Thread Emil Eifrem
On Wed, May 6, 2009 at 02:05, Antonello Provenzano antone...@deveel.com wrote:
 I will try to elaborate a plan of porting as soon as it will be
 possible, coming back to you if i will find anything that will be an
 obstacle to it. In the meanwhile, I thought that the name neo4n
 would be appropriate for the project, being the j in the name
 referred to java.

+1

Great initiative.

Cheers,

-- 
Emil Eifrém, CEO [e...@neotechnology.com]
Neo Technology, www.neotechnology.com
Cell: +46 733 462 271 | US: 206 403 8808
http://twitter.com/emileifrem
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo] neo4j on .NET

2009-05-03 Thread Anders Nawroth
Hi!

Have you tried using IKVM.NET?
http://www.ikvm.net/


/anders

Antonello Provenzano skrev:
 Emil,

 I'm a good expert on .NET architecture and technology, having
 contributed for years to the development of Mono and being a
 recognized developer and architect in this domain.

 Last week I tried to implement a port version of neo4j for .NET,
 applying the same concepts you implemented, not always plain porting
 the code: Java and C# themselves are pretty different seen from
 inside, and when you put in the middle also some architectural issues
 like transactions and such (eg. the NIO extension), the things become
 much less straight-forward.

 Although at the beginning my plan was to port in short time neo4j to
 .NET, once I analyzed the full source code I've been aware of the
 impossibility to accomplish this goal in small time: in fact, I
 decided to start the implemenation of a brand new project based on the
 concepts, rather than the actual code, of neo4j. This, as you can
 guess, requires additional work for the architectural design,
 prototyping and implementation, plus testing.

 In the short-medium term then, the best way will be to use a REST
 solution, as you suggested (but I've already considered, in case of
 not existence of native .NET solutions), which is not optimal by the
 way, although viable for the bootstrap of the project.

 I hope we will keep in touch anyway, in case i would need your and
 Neo's team assistance during the implementation of the .NET solution.

 Cheers!
 Antonello



 On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote:
   
 On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com 
 wrote:
 
 I've found that neo4j would be perfect for my scope: unfortunately, it
 is purely written in Java code and it's not portable to .NET, because
 of the massive differences between the two architectures.

 Can you tell me if is it there any language binding or any port of
 neo4j for .NET/Mono?
   
 Hi Antonello,

 There's no port and no language binding at the time. I agree with you
 that porting Neo4j to .NET would probably be require a substantial
 investment, although I'm certainly no expert at .NET.

 As for bindings, I don't know how hard that would be. Neo4j currently
 has bindings for a number of languages (Python, Jython, Ruby, Clojure)
 and sometimes they've been fairly easy to roll. The conceptual
 impedance between Java and C# is certainly close to zero, so maybe
 adding .NET bindings is not that hard. You're certainly welcome to
 give it a shot!

 Another thought: Would it work if you implemented your graph algos in
 Java using Neo4j, then wrapped them in a thin REST layer and used that
 as a backend to the rest of your app written in .NET?

 Cheers,

 --
 Emil Eifrém, CEO [e...@neotechnology.com]
 Neo Technology, www.neotechnology.com
 Cell: +46 733 462 271 | US: 206 403 8808
 http://twitter.com/emileifrem
 ___
 Neo mailing list
 User@lists.neo4j.org
 https://lists.neo4j.org/mailman/listinfo/user

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


-- 
Anders Nawroth [and...@neotechnology.com]
GTalk, Skype: anders.nawroth
Phone: +46 737 894 163
http://twitter.com/nawroth
http://blog.nawroth.com/

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


Re: [Neo] neo4j on .NET

2009-05-03 Thread Anders Nawroth
Hi!

Thanks a lot for the information.


/anders

Antonello Provenzano skrev:
 Anders,

 IKVM doesn't support the javax.transactions package.

 In fact, the main difference pointed out by neo4j between java and
 .NET is the lack of support for X/Open XA resource management: this is
 possible only by calling an interop OLEDB component, which is
 non-native .NET, which should be implemented in C++ and deployed to
 the host machine separately. Naturally, OLE development is forbidden
 in Linux machines, which makes things tougher.

 While under .NET framework (since the 2.0 specifications there's the
 inclusion of System.Transactions) it is provided a mechanism for
 transactions, architecturally different from the X/Open specifications
 (implemented with quite fidelity by javax.transactions), it is not
 provided a mechanism to handle MTS or two-phase commits.

 Since in neo4j one of the main aspects it's the XAResource
 implementation for persisting and retrieving data, the port is also
 conceptually difficult.


 Cheers.
 Antonello


 On Sun, May 3, 2009 at 9:59 AM, Anders Nawroth and...@neotechnology.com 
 wrote:
   
 Hi!

 Have you tried using IKVM.NET?
 http://www.ikvm.net/


 /anders

 Antonello Provenzano skrev:
 
 Emil,

 I'm a good expert on .NET architecture and technology, having
 contributed for years to the development of Mono and being a
 recognized developer and architect in this domain.

 Last week I tried to implement a port version of neo4j for .NET,
 applying the same concepts you implemented, not always plain porting
 the code: Java and C# themselves are pretty different seen from
 inside, and when you put in the middle also some architectural issues
 like transactions and such (eg. the NIO extension), the things become
 much less straight-forward.

 Although at the beginning my plan was to port in short time neo4j to
 .NET, once I analyzed the full source code I've been aware of the
 impossibility to accomplish this goal in small time: in fact, I
 decided to start the implemenation of a brand new project based on the
 concepts, rather than the actual code, of neo4j. This, as you can
 guess, requires additional work for the architectural design,
 prototyping and implementation, plus testing.

 In the short-medium term then, the best way will be to use a REST
 solution, as you suggested (but I've already considered, in case of
 not existence of native .NET solutions), which is not optimal by the
 way, although viable for the bootstrap of the project.

 I hope we will keep in touch anyway, in case i would need your and
 Neo's team assistance during the implementation of the .NET solution.

 Cheers!
 Antonello



 On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote:

   
 On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com 
 wrote:

 
 I've found that neo4j would be perfect for my scope: unfortunately, it
 is purely written in Java code and it's not portable to .NET, because
 of the massive differences between the two architectures.

 Can you tell me if is it there any language binding or any port of
 neo4j for .NET/Mono?

   
 Hi Antonello,

 There's no port and no language binding at the time. I agree with you
 that porting Neo4j to .NET would probably be require a substantial
 investment, although I'm certainly no expert at .NET.

 As for bindings, I don't know how hard that would be. Neo4j currently
 has bindings for a number of languages (Python, Jython, Ruby, Clojure)
 and sometimes they've been fairly easy to roll. The conceptual
 impedance between Java and C# is certainly close to zero, so maybe
 adding .NET bindings is not that hard. You're certainly welcome to
 give it a shot!

 Another thought: Would it work if you implemented your graph algos in
 Java using Neo4j, then wrapped them in a thin REST layer and used that
 as a backend to the rest of your app written in .NET?

 Cheers,

 --
 Emil Eifrém, CEO [e...@neotechnology.com]
 Neo Technology, www.neotechnology.com
 Cell: +46 733 462 271 | US: 206 403 8808
 http://twitter.com/emileifrem
 ___
 Neo mailing list
 User@lists.neo4j.org
 https://lists.neo4j.org/mailman/listinfo/user


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

   
 --
 Anders Nawroth [and...@neotechnology.com]
 GTalk, Skype: anders.nawroth
 Phone: +46 737 894 163
 http://twitter.com/nawroth
 http://blog.nawroth.com/

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

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


-- 
Anders Nawroth [and...@neotechnology.com]
GTalk, Skype: anders.nawroth
Phone: +46 737 894 163
http://twitter.com/nawroth
http://blog.nawroth.com/


Re: [Neo] neo4j on .NET

2009-05-03 Thread Antonello Provenzano
Anders,

IKVM doesn't support the javax.transactions package.

In fact, the main difference pointed out by neo4j between java and
.NET is the lack of support for X/Open XA resource management: this is
possible only by calling an interop OLEDB component, which is
non-native .NET, which should be implemented in C++ and deployed to
the host machine separately. Naturally, OLE development is forbidden
in Linux machines, which makes things tougher.

While under .NET framework (since the 2.0 specifications there's the
inclusion of System.Transactions) it is provided a mechanism for
transactions, architecturally different from the X/Open specifications
(implemented with quite fidelity by javax.transactions), it is not
provided a mechanism to handle MTS or two-phase commits.

Since in neo4j one of the main aspects it's the XAResource
implementation for persisting and retrieving data, the port is also
conceptually difficult.


Cheers.
Antonello


On Sun, May 3, 2009 at 9:59 AM, Anders Nawroth and...@neotechnology.com wrote:
 Hi!

 Have you tried using IKVM.NET?
 http://www.ikvm.net/


 /anders

 Antonello Provenzano skrev:
 Emil,

 I'm a good expert on .NET architecture and technology, having
 contributed for years to the development of Mono and being a
 recognized developer and architect in this domain.

 Last week I tried to implement a port version of neo4j for .NET,
 applying the same concepts you implemented, not always plain porting
 the code: Java and C# themselves are pretty different seen from
 inside, and when you put in the middle also some architectural issues
 like transactions and such (eg. the NIO extension), the things become
 much less straight-forward.

 Although at the beginning my plan was to port in short time neo4j to
 .NET, once I analyzed the full source code I've been aware of the
 impossibility to accomplish this goal in small time: in fact, I
 decided to start the implemenation of a brand new project based on the
 concepts, rather than the actual code, of neo4j. This, as you can
 guess, requires additional work for the architectural design,
 prototyping and implementation, plus testing.

 In the short-medium term then, the best way will be to use a REST
 solution, as you suggested (but I've already considered, in case of
 not existence of native .NET solutions), which is not optimal by the
 way, although viable for the bootstrap of the project.

 I hope we will keep in touch anyway, in case i would need your and
 Neo's team assistance during the implementation of the .NET solution.

 Cheers!
 Antonello



 On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote:

 On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com 
 wrote:

 I've found that neo4j would be perfect for my scope: unfortunately, it
 is purely written in Java code and it's not portable to .NET, because
 of the massive differences between the two architectures.

 Can you tell me if is it there any language binding or any port of
 neo4j for .NET/Mono?

 Hi Antonello,

 There's no port and no language binding at the time. I agree with you
 that porting Neo4j to .NET would probably be require a substantial
 investment, although I'm certainly no expert at .NET.

 As for bindings, I don't know how hard that would be. Neo4j currently
 has bindings for a number of languages (Python, Jython, Ruby, Clojure)
 and sometimes they've been fairly easy to roll. The conceptual
 impedance between Java and C# is certainly close to zero, so maybe
 adding .NET bindings is not that hard. You're certainly welcome to
 give it a shot!

 Another thought: Would it work if you implemented your graph algos in
 Java using Neo4j, then wrapped them in a thin REST layer and used that
 as a backend to the rest of your app written in .NET?

 Cheers,

 --
 Emil Eifrém, CEO [e...@neotechnology.com]
 Neo Technology, www.neotechnology.com
 Cell: +46 733 462 271 | US: 206 403 8808
 http://twitter.com/emileifrem
 ___
 Neo mailing list
 User@lists.neo4j.org
 https://lists.neo4j.org/mailman/listinfo/user


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



 --
 Anders Nawroth [and...@neotechnology.com]
 GTalk, Skype: anders.nawroth
 Phone: +46 737 894 163
 http://twitter.com/nawroth
 http://blog.nawroth.com/

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

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


Re: [Neo] neo4j on .NET

2009-05-03 Thread Johan Svensson
Hi Antonello,

Have a look at the neo-android component, dependency on
javax.transaction has been dropped there
(https://svn.neo4j.org/components/neo-android/trunk/) by just writing
empty interfaces for all the javax.transaction stuff needed.

javax.transaction / JTA and X/Open are just interfaces and
specifications. There is no concrete implementation or magic performed
by them so removing the dependency replacing with your own empty
interfaces should work. See org.neo4j.impl.transaction and
org.neo4j.impl.transaction.xaframework packages for the concrete
implementation of JTA, XA resources, 2PC and so on.

If it is possible to port for example the org.neo4j.impl.nioneo.store
package to .NET there should be no problem to port the transaction and
xaframework packages to .NET (they both use java.nio to manipulate
files).

Regards,
-Johan

On Sun, May 3, 2009 at 1:29 PM, Antonello Provenzano
antone...@deveel.com wrote:
 Anders,

 IKVM doesn't support the javax.transactions package.

 In fact, the main difference pointed out by neo4j between java and
 .NET is the lack of support for X/Open XA resource management: this is
 possible only by calling an interop OLEDB component, which is
 non-native .NET, which should be implemented in C++ and deployed to
 the host machine separately. Naturally, OLE development is forbidden
 in Linux machines, which makes things tougher.

 While under .NET framework (since the 2.0 specifications there's the
 inclusion of System.Transactions) it is provided a mechanism for
 transactions, architecturally different from the X/Open specifications
 (implemented with quite fidelity by javax.transactions), it is not
 provided a mechanism to handle MTS or two-phase commits.

 Since in neo4j one of the main aspects it's the XAResource
 implementation for persisting and retrieving data, the port is also
 conceptually difficult.


 Cheers.
 Antonello


 On Sun, May 3, 2009 at 9:59 AM, Anders Nawroth and...@neotechnology.com 
 wrote:
 Hi!

 Have you tried using IKVM.NET?
 http://www.ikvm.net/


 /anders

 Antonello Provenzano skrev:
 Emil,

 I'm a good expert on .NET architecture and technology, having
 contributed for years to the development of Mono and being a
 recognized developer and architect in this domain.

 Last week I tried to implement a port version of neo4j for .NET,
 applying the same concepts you implemented, not always plain porting
 the code: Java and C# themselves are pretty different seen from
 inside, and when you put in the middle also some architectural issues
 like transactions and such (eg. the NIO extension), the things become
 much less straight-forward.

 Although at the beginning my plan was to port in short time neo4j to
 .NET, once I analyzed the full source code I've been aware of the
 impossibility to accomplish this goal in small time: in fact, I
 decided to start the implemenation of a brand new project based on the
 concepts, rather than the actual code, of neo4j. This, as you can
 guess, requires additional work for the architectural design,
 prototyping and implementation, plus testing.

 In the short-medium term then, the best way will be to use a REST
 solution, as you suggested (but I've already considered, in case of
 not existence of native .NET solutions), which is not optimal by the
 way, although viable for the bootstrap of the project.

 I hope we will keep in touch anyway, in case i would need your and
 Neo's team assistance during the implementation of the .NET solution.

 Cheers!
 Antonello



 On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote:

 On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com 
 wrote:

 I've found that neo4j would be perfect for my scope: unfortunately, it
 is purely written in Java code and it's not portable to .NET, because
 of the massive differences between the two architectures.

 Can you tell me if is it there any language binding or any port of
 neo4j for .NET/Mono?

 Hi Antonello,

 There's no port and no language binding at the time. I agree with you
 that porting Neo4j to .NET would probably be require a substantial
 investment, although I'm certainly no expert at .NET.

 As for bindings, I don't know how hard that would be. Neo4j currently
 has bindings for a number of languages (Python, Jython, Ruby, Clojure)
 and sometimes they've been fairly easy to roll. The conceptual
 impedance between Java and C# is certainly close to zero, so maybe
 adding .NET bindings is not that hard. You're certainly welcome to
 give it a shot!

 Another thought: Would it work if you implemented your graph algos in
 Java using Neo4j, then wrapped them in a thin REST layer and used that
 as a backend to the rest of your app written in .NET?

 Cheers,

 --
 Emil Eifrém, CEO [e...@neotechnology.com]
 Neo Technology, www.neotechnology.com
 Cell: +46 733 462 271 | US: 206 403 8808
 http://twitter.com/emileifrem
___
Neo mailing list
User@lists.neo4j.org

Re: [Neo] neo4j on .NET

2009-05-03 Thread Johan Svensson
Antonello,

java.nio is used both for simplicity (code gets cleaner) and speed.
The transaction packages and nioneo packages can be rewritten to use
java.io but that would not perform very well. Basic file operations
needed would be:

o read/write into/from a buffer (byte array) from/to a file
o change position in a file followed by reading/writing at/to that position
o flush a file making sure all changes to that file are persisted
o file truncation is nice to have too but not absolutely needed

-Johan

On Sun, May 3, 2009 at 2:26 PM, Antonello Provenzano
antone...@deveel.com wrote:
 Johan,

 Thank you very much for the useful information and clarification: I
 will dig out and come back on this later, when I will have clearer
 view.

 Concerning the java.nio issue: in .NET there's not a counter part
 for the package. In fact, there's just the definition of the System.IO
 namespace, which provides implementations similar to java.io. The
 concepts before NIO are similar to the Remoting features of .NET, but
 the architecture is really different and not always is easily
 mappable.
 As said in my previous email, the architectural differences between
 the two technologies, specially after the latest developments (.NET,
 and C# in particular, were designed to be similar to Java and helping
 the transition of developers from one to another and reducing the
 learning curve, but latest technologies branched out of common
 aspects): *personally* I don't think that section would it be
 portable.

 Cheers.
 Antonello


 On Sun, May 3, 2009 at 2:10 PM, Johan Svensson jo...@neotechnology.com 
 wrote:
 Hi Antonello,

 Have a look at the neo-android component, dependency on
 javax.transaction has been dropped there
 (https://svn.neo4j.org/components/neo-android/trunk/) by just writing
 empty interfaces for all the javax.transaction stuff needed.

 javax.transaction / JTA and X/Open are just interfaces and
 specifications. There is no concrete implementation or magic performed
 by them so removing the dependency replacing with your own empty
 interfaces should work. See org.neo4j.impl.transaction and
 org.neo4j.impl.transaction.xaframework packages for the concrete
 implementation of JTA, XA resources, 2PC and so on.

 If it is possible to port for example the org.neo4j.impl.nioneo.store
 package to .NET there should be no problem to port the transaction and
 xaframework packages to .NET (they both use java.nio to manipulate
 files).

 Regards,
 -Johan

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


Re: [Neo] neo4j on .NET

2009-05-03 Thread Antonello Provenzano
Johan,

I see. My knowledge of NIO is pretty limited indeed: since you're
telling me it's re-designable with traditional java.io
implementations, I see no particular issues on that side (also
because, as you described some of the core functionalities, many
features are already present in System.IO). In fact, what i did know
was that NIO was used to stream remotely, opening communication
channels between the local JVM and the remote endpoint (which could
have been another running application in the same JVM).

Coming back to Transactions: it's true that JTA is just a set of
specifications abstracted by the interfaces provided (which are easily
convertible into .NET with a custom JTA packaging), but it's also true
that .NET provides a framework for handling application transactions
in the same fashion as JTA.
In fact, when a developer instantiate a TransactionScope class, opens
a transactional context for th execution of the calls withing that
instance: to support this the JTA support present in neo4j should be
adapted to the specifications provided by System.Transactions, which
don't support XA nor 2PC (heavily used by neo4j).

It's true that it would be possible to create a custom transaction
namespace within the ported neo4j, but this would change the behavior
of the application: I don't know for sure, but JTA interacts with
underlying systems for the management of transactions, as
System.Transaction does; having a custom transaction mechanism would
bypass all this.

Cheers.
Antonello


On Sun, May 3, 2009 at 2:48 PM, Johan Svensson jo...@neotechnology.com wrote:
 Antonello,

 java.nio is used both for simplicity (code gets cleaner) and speed.
 The transaction packages and nioneo packages can be rewritten to use
 java.io but that would not perform very well. Basic file operations
 needed would be:

 o read/write into/from a buffer (byte array) from/to a file
 o change position in a file followed by reading/writing at/to that position
 o flush a file making sure all changes to that file are persisted
 o file truncation is nice to have too but not absolutely needed

 -Johan

 On Sun, May 3, 2009 at 2:26 PM, Antonello Provenzano
 antone...@deveel.com wrote:
 Johan,

 Thank you very much for the useful information and clarification: I
 will dig out and come back on this later, when I will have clearer
 view.

 Concerning the java.nio issue: in .NET there's not a counter part
 for the package. In fact, there's just the definition of the System.IO
 namespace, which provides implementations similar to java.io. The
 concepts before NIO are similar to the Remoting features of .NET, but
 the architecture is really different and not always is easily
 mappable.
 As said in my previous email, the architectural differences between
 the two technologies, specially after the latest developments (.NET,
 and C# in particular, were designed to be similar to Java and helping
 the transition of developers from one to another and reducing the
 learning curve, but latest technologies branched out of common
 aspects): *personally* I don't think that section would it be
 portable.

 Cheers.
 Antonello


 On Sun, May 3, 2009 at 2:10 PM, Johan Svensson jo...@neotechnology.com 
 wrote:
 Hi Antonello,

 Have a look at the neo-android component, dependency on
 javax.transaction has been dropped there
 (https://svn.neo4j.org/components/neo-android/trunk/) by just writing
 empty interfaces for all the javax.transaction stuff needed.

 javax.transaction / JTA and X/Open are just interfaces and
 specifications. There is no concrete implementation or magic performed
 by them so removing the dependency replacing with your own empty
 interfaces should work. See org.neo4j.impl.transaction and
 org.neo4j.impl.transaction.xaframework packages for the concrete
 implementation of JTA, XA resources, 2PC and so on.

 If it is possible to port for example the org.neo4j.impl.nioneo.store
 package to .NET there should be no problem to port the transaction and
 xaframework packages to .NET (they both use java.nio to manipulate
 files).

 Regards,
 -Johan

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

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


Re: [Neo] neo4j on .NET

2009-05-03 Thread Antonello Provenzano
I dug a bit the NIO package and the use done in neo4j: unfortunately
there's not counter part for it on .NET nor the possibility to
recreate [easily] classes to support it. In fact, you make a wide and
important use of MappedByteBuffer on files: although implement the
logics of a ByteBuffer class is not difficult (in .NET schema is the
association of two classes: MemoryStream and
BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears
to be more complex, since access to portion of data in file which
access must be coordinated with the memory, and this is not a simple
issue.

As of Java implementation, this is done natively and it's a complex
operation to replicate the same functionality.

Once this is solved, I see no further [major] obstacles to the port:
avoiding the integration with the System.Transactions mechanism, the
base of neo4j port would work in its core functionalities.

Cheers.
Antonello


On Sun, May 3, 2009 at 4:51 PM, Johan Svensson jo...@neotechnology.com wrote:
 See my comments inline:

 On Sun, May 3, 2009 at 4:05 PM, Antonello Provenzano
 antone...@deveel.com wrote:
 Johan,

 I see. My knowledge of NIO is pretty limited indeed: since you're
 telling me it's re-designable with traditional java.io
 implementations, I see no particular issues on that side (also
 because, as you described some of the core functionalities, many
 features are already present in System.IO). In fact, what i did know
 was that NIO was used to stream remotely, opening communication
 channels between the local JVM and the remote endpoint (which could
 have been another running application in the same JVM).


 Yes, but we only use the native I/O part for files. Simply put, we
 want to avoid the extra copy of buffers that takes place from outside
 jvm memory to jvm buffers. NIO allows us to allocation direct buffers
 (that are allocated and managed outside the normal java heap). I also
 like the design of the nio package with channels and it is good that
 you can use the same interfaces to shuffle data over the network but
 Neo does not use those features (yet).

 Coming back to Transactions: it's true that JTA is just a set of
 specifications abstracted by the interfaces provided (which are easily
 convertible into .NET with a custom JTA packaging), but it's also true
 that .NET provides a framework for handling application transactions
 in the same fashion as JTA.
 In fact, when a developer instantiate a TransactionScope class, opens
 a transactional context for th execution of the calls withing that
 instance: to support this the JTA support present in neo4j should be
 adapted to the specifications provided by System.Transactions, which
 don't support XA nor 2PC (heavily used by neo4j).


 It should be possible to port Neo4j's transaction handling to support
 .NET's way of handling transactions. Neo will only make use of 2PC if
 there are multiple resources participating in the transaction. If you
 only use Neo and nothing else all commits will be optimized one phase
 commits.

 How would .NET handle a transaction that would like to modify
 something in two different databases in the same transactional
 context? That is what we use the two phase commit protocol for but if
 you only use Neo4j there is only one resources enlisted in the
 transaction so then it is not needed.

 It's true that it would be possible to create a custom transaction
 namespace within the ported neo4j, but this would change the behavior
 of the application: I don't know for sure, but JTA interacts with
 underlying systems for the management of transactions, as
 System.Transaction does; having a custom transaction mechanism would
 bypass all this.


 Yes, also it might be possible to just write some glue code between
 the .NET TransactionScope and the NeoService.beginTx() 
 org.neo4j.api.core.Transaction classes. If all you need is single
 resource, begin,commit and rollback it would be much easier to
 integrate there and just do a straightforward port of the transaction
 package.

 Regards,
 Johan

 Cheers.
 Antonello


 On Sun, May 3, 2009 at 2:48 PM, Johan Svensson jo...@neotechnology.com 
 wrote:
 Antonello,

 java.nio is used both for simplicity (code gets cleaner) and speed.
 The transaction packages and nioneo packages can be rewritten to use
 java.io but that would not perform very well. Basic file operations
 needed would be:

 o read/write into/from a buffer (byte array) from/to a file
 o change position in a file followed by reading/writing at/to that position
 o flush a file making sure all changes to that file are persisted
 o file truncation is nice to have too but not absolutely needed

 -Johan

 On Sun, May 3, 2009 at 2:26 PM, Antonello Provenzano
 antone...@deveel.com wrote:
 Johan,

 Thank you very much for the useful information and clarification: I
 will dig out and come back on this later, when I will have clearer
 view.

 Concerning the java.nio issue: in .NET there's not a counter part
 for the package. 

[Neo] neo4j on .NET

2009-05-02 Thread Antonello Provenzano
Hi all,

I've been designing an application, based on .NET/Mono framework,
which should make an heavy use of the shortest-path in a graph
theories and I would like to use a native solution to traverse the
nodes of the graph, instead of implementing surrogate solutions which
would be hardly maintainable and would massively affect performances.

I've found that neo4j would be perfect for my scope: unfortunately, it
is purely written in Java code and it's not portable to .NET, because
of the massive differences between the two architectures.

Can you tell me if is it there any language binding or any port of
neo4j for .NET/Mono?


Thank you all
Antonello
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo] neo4j on .NET

2009-05-02 Thread Emil Eifrem
On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com wrote:
 I've found that neo4j would be perfect for my scope: unfortunately, it
 is purely written in Java code and it's not portable to .NET, because
 of the massive differences between the two architectures.

 Can you tell me if is it there any language binding or any port of
 neo4j for .NET/Mono?

Hi Antonello,

There's no port and no language binding at the time. I agree with you
that porting Neo4j to .NET would probably be require a substantial
investment, although I'm certainly no expert at .NET.

As for bindings, I don't know how hard that would be. Neo4j currently
has bindings for a number of languages (Python, Jython, Ruby, Clojure)
and sometimes they've been fairly easy to roll. The conceptual
impedance between Java and C# is certainly close to zero, so maybe
adding .NET bindings is not that hard. You're certainly welcome to
give it a shot!

Another thought: Would it work if you implemented your graph algos in
Java using Neo4j, then wrapped them in a thin REST layer and used that
as a backend to the rest of your app written in .NET?

Cheers,

-- 
Emil Eifrém, CEO [e...@neotechnology.com]
Neo Technology, www.neotechnology.com
Cell: +46 733 462 271 | US: 206 403 8808
http://twitter.com/emileifrem
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo] neo4j on .NET

2009-05-02 Thread Antonello Provenzano
Emil,

I'm a good expert on .NET architecture and technology, having
contributed for years to the development of Mono and being a
recognized developer and architect in this domain.

Last week I tried to implement a port version of neo4j for .NET,
applying the same concepts you implemented, not always plain porting
the code: Java and C# themselves are pretty different seen from
inside, and when you put in the middle also some architectural issues
like transactions and such (eg. the NIO extension), the things become
much less straight-forward.

Although at the beginning my plan was to port in short time neo4j to
.NET, once I analyzed the full source code I've been aware of the
impossibility to accomplish this goal in small time: in fact, I
decided to start the implemenation of a brand new project based on the
concepts, rather than the actual code, of neo4j. This, as you can
guess, requires additional work for the architectural design,
prototyping and implementation, plus testing.

In the short-medium term then, the best way will be to use a REST
solution, as you suggested (but I've already considered, in case of
not existence of native .NET solutions), which is not optimal by the
way, although viable for the bootstrap of the project.

I hope we will keep in touch anyway, in case i would need your and
Neo's team assistance during the implementation of the .NET solution.

Cheers!
Antonello



On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote:
 On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com 
 wrote:
 I've found that neo4j would be perfect for my scope: unfortunately, it
 is purely written in Java code and it's not portable to .NET, because
 of the massive differences between the two architectures.

 Can you tell me if is it there any language binding or any port of
 neo4j for .NET/Mono?

 Hi Antonello,

 There's no port and no language binding at the time. I agree with you
 that porting Neo4j to .NET would probably be require a substantial
 investment, although I'm certainly no expert at .NET.

 As for bindings, I don't know how hard that would be. Neo4j currently
 has bindings for a number of languages (Python, Jython, Ruby, Clojure)
 and sometimes they've been fairly easy to roll. The conceptual
 impedance between Java and C# is certainly close to zero, so maybe
 adding .NET bindings is not that hard. You're certainly welcome to
 give it a shot!

 Another thought: Would it work if you implemented your graph algos in
 Java using Neo4j, then wrapped them in a thin REST layer and used that
 as a backend to the rest of your app written in .NET?

 Cheers,

 --
 Emil Eifrém, CEO [e...@neotechnology.com]
 Neo Technology, www.neotechnology.com
 Cell: +46 733 462 271 | US: 206 403 8808
 http://twitter.com/emileifrem
 ___
 Neo mailing list
 User@lists.neo4j.org
 https://lists.neo4j.org/mailman/listinfo/user

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