Comments on: FluidDB: The Next Web Paradigm?

By: bruce wayne

bruce wayne — Mon, 25 Jan 2010 15:40:59 +0000

Maybe FluidDB could try to do something different that would make it dead simple to use and that would hide the complexities of a database….There is a reason that most people dont use them or like to use them…they reek of complexity….

By: Twitter Trackbacks for FluidDB: The Next Web Paradigm? | Provoking: The blog of Filip Dousek [dousek.com] on Topsy.com

Sun, 30 Aug 2009 11:33:01 +0000

[...] FluidDB: The Next Web Paradigm? | Provoking: The blog of Filip Dousek http://www.dousek.com/2009/04/13/fluiddb-the-next-web-paradigm – view page – cached What will the first applications built on FluidDB do, and what does it mean for the web? — From the page [...]

By: Filip Dousek

Filip Dousek — Thu, 16 Apr 2009 14:39:41 +0000

Thank you, Mike. When you are in Barcelona, ask Terry about the door that could be a movie, you will like it :-)

By: Mike Hedge

Mike Hedge — Thu, 16 Apr 2009 08:26:25 +0000

Filip thank you for posting this blog. Terry rocks. can’t wait for the launch.

Mike Hedge
http://www.mikehedge.com

By: Filip Dousek

Filip Dousek — Tue, 14 Apr 2009 21:20:06 +0000

Hi Otoburb,

I was suggesting Twitter as an analogy to the applications’ business models rather than Fluidinfo’s, although it is a good reference point for Fluidinfo as well. And I agree that FluidDB offers more monetization options than Twitter, plus, some of them could be passed on to the applications.

On both your questions, I assume what you assume :)

I spoke with Terry about charging for objects and how that would influence the landscape, and it seemed to be a possibility.

Glenn, Terry is pretty positive on the progress, the pieces are starting to fit together. Looking forward as well ;)

By: tired fools :: hypothesis generation :: April :: 2009

tired fools :: hypothesis generation :: April :: 2009 — Mon, 13 Apr 2009 23:48:31 +0000

[...] whether this is going to work well enough we’ll discover in time (launch next month). but whatever it yields will be improved upon. we’re getting better at analysing data. we’re also getting better, and smarter, at creating it. something else that’s launching soon, fluidDB. [...]

By: otoburb

otoburb — Mon, 13 Apr 2009 21:12:24 +0000

Just read the Gerry Campbell’s post (embedded above) and read the comments from Terry regarding a comment I had above:
“One difference is that Freebase are really into big honking datasets, whereas that’s not my initial interest at all.”

By: Glenn Willen

Glenn Willen — Mon, 13 Apr 2009 21:01:01 +0000

When do us plebes get access to FluidDB? :-) I would kill to have this — I have built a system like this for my own use, out of spit and baling wire (read: Perl and text files), and I’ve long contemplated making a shared, federated version. It really sounds like FluidDB is exactly my vision, so I’m very excited to try it, and see if I can coerce it into being the thing I would have created. ;-)

One application I’m contemplating is a federated global ontology; from the “semantic web” I hear getting thrown around, it sounds like this may be a design goal of FluidDB, in which case I’m very excited…

By: otoburb

otoburb — Mon, 13 Apr 2009 20:45:00 +0000

If FluidDB can act in a similar way to how ICANN organizes domain names, then this will be a dynamite revenue model. It’s unsure how Twitter will monetize, but FluidDB has the capability not just to store preferences, but also entirely open message stores (if so chosen by the users) or any other type of blob.

Preferences (and bookmarks) are surely the low-hanging fruit. I wonder if Terry and Esteve plan to set object size limits, or start charging for storage costs that become non-negligible.

FluidDB often reminds me of a massively mutiplayer (and continuously persistent) universe for people to explore and partake in.

Two questions that immediately come to mind are:

1) Does FluidDB allow one to export one’s data at no cost? (I assume the answer is yes, but this will probably show up on a FAQ somewhere)
2) Are there plans to have separate FluidDB-like architectures that can communicate to each other (i.e. separate datastores)? If not, how does FluidDB expect to deal with copycats using their open-sourced txAMQP and txThrift work? (I am assuming that the answer would be that a) nobody would want to re-implement an already existing cloud-service for no other reason that to house your own (enterprise?) data internally w/ selective sharing); b) people would not be able to catch up to the refinements that Terry and Esteve have designed and implemented to make FluidDB the platform that it will become).