Open sourcing Tickery(blogs.fluidinfo.com)
blogs.fluidinfo.com
Open sourcing Tickery
http://blogs.fluidinfo.com/fluidDB/2010/07/20/open-sourcing-tickery/
1 comments
I'd be happy to answer questions about Tickery. The point of it is not what it appears to be from just looking at the web app. Read the Huh? dialog on the advanced tab, and also see the text on the About tab. It's not really about sets of Twitter friends, it's about FluidDB and what happens when an app (e.g., Tickery) stores its data into an openly writable database.
FluidDB is very exciting technology once one gets past the initial "WTF". I'm looking forward to more user-facing applications.
Not really a Tickery question, but I'm curious about how one could extract subsets of data for off-line use and then replicate this when back online. Understanding that the plan is to open-source FluidDB, what kind of resources would be required to run a "mini-FluidDB"?
Not really a Tickery question, but I'm curious about how one could extract subsets of data for off-line use and then replicate this when back online. Understanding that the plan is to open-source FluidDB, what kind of resources would be required to run a "mini-FluidDB"?
Hi. I don't really know the best way to do this, though I have thought about it over the years. I think things like Google Gears will be a big help with this sort of thing. But it should also be possible to write smart client-side libraries that let you you modify objects locally and only sync when they can. That would certainly be fine for new objects you create, and for tags you have control over, but would be more involved if you (and others) were offline changing tags over which you all had control. Those kinds of things tend to run into difficult issues - which is mainly why I say I don't know how to solve this (fully). Running a mini client-side FluidDB shouldn't be too hard, especially with things like sqlite being built into some browsers. But again, lots and lots of details.....