Hi,

I asked a question on IRC whether the fluiddb/about tag would stay as
is, or whether there would be a push to rename the most important tag
in the platform to fluidinfo/about.
The current feeling of the Fluidinfo team is such a change would be
rather disruptive, as this would clearly break API compatibility with
current language libraries and tools.

The idea of making 'fluidinfo' a synonym of 'fluiddb' was considered
by Jamu Kakar (@jkakar) but this may not be straightforward for the
following reasons:
1) If you specify 'fluidinfo/about', should the platform respond back
with 'fluidinfo/*' tags, or respond back with whatever the original
request specified?
2) Building in logic to detect the alias will slow down all requests
(but only a bit), and will add more code paths to test.

Ultimately, the question boils down to: "is it worth it?"

Only the Fluidinfo team can make the call on this, although it would
be good to hear back from the developers of the existing Fluidinfo
libraries to see what they think too.
This probably won't matter at all to end-users who will rarely (if
ever) see the raw tag names or paths to care, but since developers
seem to appreciate clean and consistent APIs, I figured this was worth
a mention.

Davison

I for one would have no problem updating Net::Fluidinfo. Indeed when I updated the module to reflect the change (which touched an entire namespace of classes and documentation), I wondered about the about tag.

So just expressing my willingness to update the code right away. I think consistency/branding trumps compatibility at this stage and would find natural to rename also the fluiddb namespace.

Of course the Fluidinfo team is the one to gauge the convenience of such rename, whatever they decide is fine. In the real world inconsistencies happen, and Fluidinfo is about the real world :)... hmmm that would become a consistent inconsistency which is very nice indeed!

Top-posted from my iPad while having breakfast

El 8 Apr 2011, a les 00:07, otoburb <otob...@gmail.com> va escriure:

Davison

Interesting question.

Personally, I dislike the fact that the about tag includes a namespace  
at all: I've always thought it should be simple about (or /about),  
reflecting the reality that it is a system-wide tag with special  
properties.*   I would also like to be able to refer to the id of an  
object as id or /id.

I think, as a general principle, embedding the product name more than  
is necessary inside a product is nearly always a mistake.   Why do all  
the methods in Apple APIs include the cryptic "NS"?   Why, because NS  
stands for NextStep, of course.   Similarly, my last company,  
Quadstone, got acquired by Portrait Software, which was then acquired  
by Pitney Bowes; but I would be prepared to wager that there still an  
awful lot of methods in the software that start QS or qs...    
Fluidinfo has already changed its name once, and history suggests that  
it's more than likely it will do so again, whether because of a change  
of mind, a trade mark dispute or a corporate reorganization.  (Perhaps  
in 2015 or 2016 Fluidinfo will acquire Google, but the price of the  
deal will be that the new entity will be called Google, or Gooinfo or  
Gloop.   Or perhaps it will buy Microsoft and become Softinfo, or buy  
Apple and become AppleJuice.)

Given that I think the name was always inappropriate and is now  
obsolescent, I don't see that changing to something transiently  
appropriate but probably soon obsolescent is worth the undoubted pain  
involved; but changing it to a neutral about or /about would be a  
change that might actually be worth the pain.

It should also be pointed out that it's not just library developers,  
but users who will affected by the change. As it happens, users of my  
library, fdb.py, could be at least somewhat insulated because I have  
always provided /about and /id as virtual tags, so if I just remapped /
about to fluidinfo/about (from fluiddb/about) some user code would  
continue working.   The insulation wouldn't be complete, however, as  
user code still might include and explicit fluiddb, and I never got  
around to carrying the change through to the query syntax anyway.

Nick

* I believe Terry's reason for sticking the about tag under the  
fluiddb namespace is that he's attached to the idea that FluidDB (as  
was) is "just another" application on top of the underlying data  
store. I've never thought this was particularly compelling in  
principle, and I have never been completely convinced it's true  
either, though Terry's probably right.    It may well also be true  
that the code has hardwired assumptions that all tag paths start with  
a namespace, so that in practice, getting rid of the namespace would  
be a lot of work...

On 7 Apr 2011, at 23:07, otoburb wrote:

Hi Davison

fluiddb/about appears in many places. In slide presentations, images,
documentation, video tutorials, the code base, application code, client
libraries, blog posts, etc.

We decided not to break all of these at once and to live with the
historical accident. The easiest way to think about it is that fluiddb is
the name of the admin user in Fluidinfo. Just like UNIX has an admin user
called root.

It's unlikely that we'd do that. In general we don't like to introduce
alternate ways to do things (/objects and /values is an exception).
Creating equivalent choices makes things less clear/specific, makes for
more documentation, more code to be supported, and tends to multiply
things.  We're pretty strongly in the Python camp of TOOWTDI rather than
Perl's anything goes TMTOOTDI.

Yes, agreed, thanks.

Terry

Long live that.

But on the matter of "acronyms are evil": Is TMTOOTDI a typo/thinko?    
I presume you mean "There's more than one way to do it" (TMTOWTDI).    
Or it it a variation I don't know?

TLAs: just say no.   XTLAs:* just say never!

Nick

* IBM's 'eXtended three-letter abbreviations'

Hi Nick

Yes, understood :-) The reason it's in the fluiddb namespace is for
consistency and simplicity. Apart from being unique valued, it really is
just another tag. The code base, including the query parsing, is simpler if
all tags live in a namespace. It's perhaps not a good argument, but we've
always cared about keeping things simple/consistent in order to (ideally)
be able to have cleaner internal code. Writing code to properly support
UNIX path names has weird corner cases (though they have to deal with
problematic things like ..). In my experience those kinds of things with a
number of different special cases often have exhibit a tendency for the
mess to leak out and cause ambiguities/uncertainties in surrounding code.
That will probably sound like a weak argument, but I think it's important.

This goes back to Davison's mention of the possibility of supporting
fluidinfo as an alternative to fluiddb. Once you start allowing multiple
ways to do things, those things tend to multiply. Here we'd just have 2x2,
but even that is too much. TOOWTDI keeps it at one.

We made the pragmatic choice to minimize disruption, to start regarding
fluiddb as just a user name, and to leave it all alone. I don't like it at
all, and I wish it were gone, along with application/vnd.fluiddb.value+json
and the FluidDB-* response headers. Living with it is a lot less work and a
lot less damaging than causing all libraries to be out of date. Returning
both kinds of headers or accepting both kinds of Content types is another
internal multiplication of code/cases, as above.

I wouldn't say application, but user. We have an internal variable called
adminUserName = "fluiddb". It makes everything consistent: the tag is owned
by a user, it is subject to regular permissions checking (*nothing* is
different), it is not actually immutable, it's just that the user (fluiddb)
who controls it doesn't ever change or remove it, its name can be parsed
and recognized as a tag name just like any other tag in the system. These
are lead to uniformity & simplicity.

As you can tell from all the things in this mail and the one to Davison, we
care a lot about keeping Fluidinfo simple internally. Perhaps more than we
should, but I think if you're not strict about those things,
complexity/alternatives creep in and (as above) tends to multiply when it
bumps into other complexity/alternatives.

It would just create special cases. The most work would be fixing some
other things mentioned in the mail to Davison. As you suggest, once a tag
path in a query or a tag path coming into the API from a regular method
enters the system, you know you can always split it on '/'. No exceptions,
literally :-)

Sorry if this was a bit repetitive / long-winded.

T

Yep. Sorry!

T

Hi Terry

Sure.

I'm not so sure I agree with that. I'm fairly sure that from an  
external perspective life would be a lot simpler if ID were just  
another tag too (albeit one that had a close relationship to about  
tags).   But I agree that starting from the code/API as it actually  
is, you're right.

I agree completely with that.

Agreed.

Maybe fluiddb should be renamed the empty string.   Then it would  
really be /about, the name would be application-name neutral, and  
"we'd both be happy".

$ python
Python 2.6.5 (r265:79359, Mar 24 2010, 01:32:55)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

 >>> '/about'.split('/')
['', 'about']

No exceptions, literally :-).   Call me .

Nick

Hi Nick,

Sometimes it seems a bit weird to me that things like an object's ID
or a namespace's path are represented as tags at all.  I can see how
it's consistent, in a way, but it also causes problems because they
aren't normal tags, they're "special things".

I wonder if we'd have an easier time if we stopped thinking about
these special properties as tags...?  On the other hand, having fewer
concepts to understand is a good thing, so maybe the "every bit of
data is a tag/value" is actually the best situation we could have.

From 'import this' in Python:

Namespaces are one honking great idea -- let's do more of those!

Making the child namespaces of 'fluiddb' top-level ones, which is
basically what would happen if you renamed 'fluiddb' to '', would mean
you'd have at least these new top-level namespaces:

about
default
id
namespaces
tags
tag-values
users

Which would be pretty bad.  In addition to polluting the root
namespace, they'd be hard to discover.  It's very nice that you can
use the API to discover the builtin tags and namespaces.  Also, we'd
be hamstrung if we wanted to add something new, like 'role' for
example, and it turned out there was a user with that name.

We've already decided that the disruption caused by a rename is too
high, but even then, removing the top-level namespace would cause more
problems than it solves.

Thanks,
J.

On 8 Apr 2011, at 09:42,

Well, my suggestion was admittedly slightly tongue-in-cheek, but I  
think you've misunderstood (either that, or I have).   As far as I can  
see, if you renamed the fluiddb user to '' none of what you describe  
would happen.   If there were a user called 'about' that user would  
continue.   If she had a tag called 'foo', that would be the tag

about/foo

which wouldn't conflict at all with the root ('') user's tag

/about

Same for the others.

I don't really think Fluidinfo is going to make the change I'm  
suggesting, but I don't think it would cause any of the problems  
you're describing.

Nick

Hi Nick,

Ah, okay, I had misunderstood.  I thought your /about example adding a
leading slash to the tag path, like the one that is present in a UNIX
path such as /home/jkakar.

Thanks,
J.

Admittedly, that has been my longer-standing desire.   If we'd  
engineered it like that from the beginning, I still think it would  
have been better; but obviously we didn't.

Nick

Hi Nick,

Out of curiosity, why do you think a leading slash is a good thing?
My feeling, so far, is that it's an unnecessary extra character.  I
guess I also don't tend to think about tag and namespaces paths in
terms of UNIX filesystems.  I can see the relation, of course, but
I don't think we should be constrained by UNIX conventions.

Thanks,
J.

Funnily enough, a lot of the motivation is to save typing.   I like  
relative paths, and to support those you need a way to distinguish the  
absolute from the relative.   The leading slash does that.   I have  
two different shell-like implementations for Fluidinfo that both allow  
relative and absolute paths.   In the first, fdb.py, relative paths  
are assumed to be in the user's space (in my case, normally, njr).    
This makes a huge difference in practice.   I say things like

fdb tag -a "Jamu" rating=10 met=true

It feels ridiculous to me to have to specify njr each time:

fdb tag -a "Jamu" njr/rating=10 njr/met=true

My second FluidDB shell is part of Miró (my data analysis suite).    
That actually supports all the main unix analogues--- cd, pwd, ls,  
~, .., relative and absolute paths, and it makes tagging and looking  
at tags really easy.

Now, I know an obvious retort is "well fine, you have a shell to do  
that, but Fluidinfo itself is like the kernel, and the kernel only  
ever uses absolute paths". But it's really ugly when full paths are  
different in the shell and in the kernel.   (Obviously, in Unix, they  
aren't.)

I do, and I find it works really well.   The only point at which the  
analogy breaks down, for me, is that in Fluidinfo you can have a  
namespace (directory) and a tag (file) with the same path.   I don't  
really like that either as it means that the path doesn't determine  
the object.

I half agree.   Clearly, we shouldn't be constrained.   But over the  
years I've built many things that are similar-to-but-sightly-different  
from something else, usually improving on various minor aspects,  
fixing things I see as defects.   Though it's hard to generalize,  
overall I think a good principle is only to vary things when there's a  
strong reason to do so.   This is partly because people get confused  
by things that are mostly the same but not quite.   (The similarities  
help until you come to a difference, and then they become a  
nuisance.)   And it's partly because there are often good reasons for  
things being the way they are, that only become fully apparent later.

Obviously, I accept that taken too far, this simply stifles progress,  
and would equally accept that just as often as things are the way they  
are for a good reason, they're the way they are as a result of  
oversight, laziness, inexperience or lack of clarity.

But I don't think the leading slash falls into that category at all.    
To my mind, it serves an clear dual purpose --- denoting the start of  
a path that it's often useful to abbreviate, and facilitating the use  
of relative as well as absolute paths.

Sorry for the long-winded reply; but you did ask.

Nick