fluiddb/about vs.fluidinfo/about
otoburb
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
Xavier Noria
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 <oto...@gmail.com> va escriure:
Nick Radcliffe
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...
Terry Jones
> 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.
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.
> 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.
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.
> 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.
Yes, agreed, thanks.
Terry
Nick Radcliffe
> Perl's anything goes TMTOOTDI.
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'
Terry Jones
> 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.*
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.
> I would also like to be able to refer to the id of an object as id or
> /id.
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.
> 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.
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 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.
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 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...
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
Terry Jones
Yep. Sorry!
T
Nick Radcliffe
>
> Hi Nick
Hi Terry
Sure.
>> I would also like to be able to refer to the id of an object as id or
>> /id.
>
> 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.
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.
>> 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.
>
> 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 agree completely with that.
Agreed.
>> 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...
>
> 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 :-)
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
Jamu Kakar
On Fri, Apr 8, 2011 at 10:28 AM, Nick Radcliffe <n...@radcliffe0.com> wrote:
>>> I would also like to be able to refer to the id of an object as id or
>>> /id.
>>
>> 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.
>
> 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.
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.
>>> 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...
>>
>> 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 :-)
>
> 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".
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.
Nick Radcliffe
On 8 Apr 2011, at 09:42,
>> 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".
>
> 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.
>
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
Jamu Kakar
On Fri, Apr 8, 2011 at 11:10 AM, Nick Radcliffe <n...@radcliffe0.com> wrote:
> 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.
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.
Nick Radcliffe
> 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
Jamu Kakar
On Fri, Apr 8, 2011 at 11:19 AM, Nick Radcliffe <n...@radcliffe0.com> wrote:
>> 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.
>
> 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.
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.
Nick Radcliffe
> My feeling, so far, is that it's an unnecessary extra character.
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 guess I also don't tend to think about tag and namespaces paths in
> terms of UNIX filesystems.
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 can see the relation, of course, but
> I don't think we should be constrained by UNIX conventions.
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