[fluiddb-discuss] Server-side code?

[Jeremy Dunck]

I was thinking a DSL for server-side processing of the API would be
very useful. Some use cases I have thought of for Fluid require
massive tag writing and moving. The main bottleneck, AFAICS, is the
network latency for processing.

(I'd like python server side better, but I assume a DSL would be
easier to safely implement.)

Is this something that might be implemented?

[Nicholas Tollervey]

Hi Jeremy,

You've seen Ali Afshar's FOM..?

http://bitbucket.org/aafshar/fom-main/wiki/Home

It's a very impressive OO wrapper for FluidDB written in Python (Ali
is aa_ on the IRC chan).

Regarding "latency" - some of this is because to retrieve data from
FluidDB one often has to HTTP GET for each tag you're interested in
for each object that matches a certain criteria (a potentially huge
number of requests). This will change (soonish) with a new version of
the QL that will allow you to do something equivalent to the following
SQL-esque query: SELECT foo, bar WHERE baz > qux that'll return a json
query. Suddenly all those queries get reduced to one.

Hope this help,

Nicholas.

[Jeremy Dunck]

On Fri, May 14, 2010 at 3:12 AM, Nicholas Tollervey
<ntoll...@gmail.com> wrote:
> Hi Jeremy,
>
> You've seen Ali Afshar's FOM..?
>
> http://bitbucket.org/aafshar/fom-main/wiki/Home
>
> It's a very impressive OO wrapper for FluidDB written in Python (Ali
> is aa_ on the IRC chan).

I have actually played with FOM a bit. And I agree that the query
syntax (I read the spec a while back) will save a lot of round trips.
But what if I'm write-heavy? :-)

One thing I'm thinking about doing is to make an ID cross-reference
for common social objects. Objects using tags to match up last.fm id
to musicbrainz id, for example. Most of this run time will be network
round-tripping.