Fedone does not persist data

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a fedone account
2. Create a wave.
3. Reload the fedone account.

What is the expected output? What do you see instead?
The expected output would be to see the wave you created on the previous 
session. The actual 
output is a blank wave list.

What version of the product are you using? On what operating system?
build 120 on Solaris 10/SPARC64

Please provide any additional information below.
This is an "improvement", which is completely obvious but perhaps should be in 
the list of issues 
as such.

Original issue reported on code.google.com by GeekChiq...@gmail.com on 16 Dec 2009 at 9:19

[GoogleCodeExporter]

Original comment by btkalman@gmail.com on 16 Dec 2009 at 11:17

• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

There's Anthony Watkins' MongoDB patch, which we're in the process of reviewing 
for 
possible addition to FedOne. See http://codereview.waveprotocol.org/44001/show 
- if 
you try it out, let us know what your experiences are.

Original comment by anthonybaxter@gmail.com on 16 Mar 2010 at 4:43

[GoogleCodeExporter]

I haven't tested this out, as compiling software on Solaris is a pain in the 
neck - and at the moment I have a 
very limited internet connection. I will attempt to do so, but I do think that 
there's a few problems with 
integration with MongoDB that I would consider before adding it as a patch.

1: MongoDB is under the APL, which is a far more restrictive license than 
FedOne itself.
2: It's a C++ program, unlike FedOne - which means it needs to be compiled for 
a specific system. In 
contrast, both OpenFire and FedOne can be compiled on one platform and run on 
any other - I compiled on 
Ubuntu i386 for a Solaris SPARC64 system! HSQLDB would be a much better choice 
for both reasons 1 and 2.
3: Wouldn't it be more appropriate to utilise a generic SQL link as well as SQL 
Schema, similar to OpenFire?

Original comment by GeekChiq...@gmail.com on 16 Mar 2010 at 6:12

[GoogleCodeExporter]

Hi GeekChique,

I wanted to see if I could address some of the concerns in your post.  One of 
the 
good things about mongoDB is the range of the community.  This leads to 
pre-compiled 
versions for many platforms.  They have a pre-built database for OS X 32&64bit, 
Linux 
32&64 bit, Windows 32&64 bit, Solaris i86pc, and Solaris 64.  They also have 
package 
managers for MacPorts, FreeBSD, Homebrew, and ArchLinux (I haven't looked into 
these).  The source of MongoDB may also be downloaded and built. The download 
information is here: http://www.mongodb.org/display/DOCS/Downloads

In terms of freedom of use, the mongoDB licensing page states 

"If you are using a vanilla MongoDB server from either source or binary 
packages you 
have NO obligations. You can ignore the rest of this page."  

AGPL applies when a user wants to edit the code of mongoDB.  I do not know if 
the 
ability to modify the underlying code of the database used for FedOne is an 
important 
requirement in choosing a persistence mechanism (it may indeed be for some).  
If the 
goal is to modify and distribute a modified mongoDB the restriction is:

"If you intend to modify the server and distribute or provide access to your 
modified 
version you are required to release the full source code for the modified 
MongoDB 
server. To reiterate, you only need to provide the source for the MongoDB 
server and 
not your application (assuming you use the provided interfaces rather than 
linking 
directly against the server)."

It does not seem as if this would be too big an impediment for the majority of 
FedOne 
users.  As far as using generic SQL, I can certainly understand that as a 
rational 
viewpoint.  I happen to be in the camp that a non-relational DB suits the needs 
of 
FedOne a little better, but this will ultimately come down to preference and 
familiarity.  In either case, I have attempted in the design to abstract the DB 
implementation out of the interface.  You should be able to take the code and 
substitute HSQL if that is your preference.  Here is the post where I discuss 
the 
design principles I used: http://www.angleofsight.com/2010/03/mongowave/ .

I sincerely thank you for taking the time to review and comment on the mongoDB 
persistence mechanism. I hope it can meet your base needs and perhaps even 
provide a 
framework for you to implement your preferred solution.  Best of luck to you.

R,

Anthony

Original comment by awatkins03@gmail.com on 18 Mar 2010 at 2:41

[GoogleCodeExporter]

Hi Athony, thanks for responding!

Firstly, you've done the work and I haven't - so all props to you there, and 
nothing bad can be said against it! 

In an open source project like FedOne, it's not unreasonable to assume that 
someone might want to modify 
the code of the database server - including organisations who are unable to 
release their source code, and 
introducing a dependance on a sharealike licensed product is to me, a bad thing.

In terms of cross-platform usage, how about Haiku-OS? They have part of a Java 
virtual machine already! 
Similar to the licensing issue I have above, it's all about consistency. Should 
I be using OpenFire and FedOne 
on a Haiku Server (For example my PowerPC XServe, when the Haiku Port matures - 
this is just an example) 
and the machine dies or a vulnerability in Haiku emerges - I can pick up my 
entire system and drop it on 
another machine - switch on and go, more-or-less. Equally, should I wish to 
distribute FedOne on a disc to 
people, With a fully java system I can provide the three java packages - and 
once again I have an essentially 
turnkey system. This is not possible when the database is non-java.

Again, I have no complaints about your work and think it's a fantastic thing to 
have provided the community. 
The patch is incredibly valuable for people currently setting up wave servers 
who want to add persistence to 
the system (A key goal for building a workable system to be actually used.) 
Should I manage to grab the time, 
I would likely use your code and framework as a basis for implementing a 
generic storage system. (Note to 
any good Java developers interested in that task - My Java's rubbish, and I'm 
heavily oversubscribed.. Don't let 
me stop you from doing the work first!)

Until the storage framework is able to be hooked into at least HSQL (As a 
non-sharealike java db example) as 
well as MongoDB, I at least feel that it shouldn't be included in the core 
branch of FedOne, but offered as a 
branch or a patchset for those who want to use it. The more people who provide 
a response on this the 
better, that's simply my thoughts on the matter!

Thanks,
Gray.

Original comment by GeekChiq...@gmail.com on 18 Mar 2010 at 8:04

[GoogleCodeExporter]

The MongoDB specific parts of the patch are limited to 2 files. I think the 
priority
should be to get some kind of persistence into fedone, then the work can be 
done to
allow pluggable storage engines.

Once there is a way of implementing pluggable storage engines then all 
arguments for
the merits of a particular DB can always be accompanied with a patch ;)

Fedone is currently a monolithic codebase which needs splitting up for reasons 
other
than MongoDB, so I see this as a separate work stream.

Original comment by steve.t....@gmail.com on 18 Mar 2010 at 6:31

[GoogleCodeExporter]

I agree with Steve Baker, and I was considering it yesterday. For what it's 
worth, 
something like Hibernate is a little trickier than a schema-free DB like 
MongoDB or 
CouchDB. 

Not sure what you mean about "splitting up" the fedone codebase - note the 
difference 
between the code in examples/fedone and the rest of the code.

Original comment by anthonybaxter@gmail.com on 18 Mar 2010 at 9:21

[GoogleCodeExporter]

Progress update: we're working on defining a wave store interface and an 
initial MongoDB implementation

Original comment by ano...@google.com on 14 Sep 2010 at 11:39

• Changed title: Fedone does not persist data
• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

Design for a filesystem-based wave store for a simple small-scale store to 
start: 
http://www.waveprotocol.org/protocol/design-proposals/wave-store-design-for-wave
-in-a-box

Original comment by ano...@google.com on 6 Nov 2010 at 7:31

[GoogleCodeExporter]

Change status to fixed?

Original comment by vega113 on 23 Feb 2011 at 8:25

[GoogleCodeExporter]

Fixed in revision 84e762b3bd.

Original comment by so...@google.com on 23 Feb 2011 at 11:26

• Changed state: Fixed