Previous Entry Share Next Entry
Release 0.4.0-RC1 -- aka Alpha Release Candidate 1
querki
jducoeur wrote in querki_project
Finally.

It's been a *long* time since I posted one of these release announcements. (Almost two months -- an eternity by my standards, given that I prefer to release a couple of times a week.) Partly that's because of Real Life -- the little matter of getting married and going on a honeymoon in the middle of that span, which is a bit distracting -- and I'm not concerned about that. But mostly it's because I finally sat down and dealt with the terribly messy problem of letting other people use Querki.

Really, it's a fine example of Code Debt. As of 0.3.22 (August 29th), it was still the case that all the logins in the system were hard-coded. Going from that to working properly in the database wasn't too hard. But implementing the whole invitation system -- that required finally wrestling with a lot of stuff I'd been putting off.

What's New

Most of it isn't user-visible, but here are the high points.

Sharing and Security: the Actions menu now has a "Sharing and Security" menu option. This is currently only enabled for the Owner of the Space. (Eventually, the Owner will be able to delegate Managers who can share in these sorts of activities, but I don't think we need that yet.) The "Security" part of this isn't done yet (it will eventually provide a better UI for some of the primitive security functionality), but this page now lets you invite people to join in your Space, see the Members, and so on.

Invitations are, for the moment, handled by email. You can invite anybody you want to share in the Space, by specifying their email address; this sends an invitation to them via email. (Your email is given as the Reply-To for the time being. This isn't optimal, and will likely change over time, but my experience with my Wedding Space was that people are going to try to reply to the email no matter what you say, so we should handle that gracefully. It is open to discussion at the moment.)

To respond to an invitation, you sign up for a Querki account, and that becomes active immediately. Initially, you can only participate in Spaces that you have been invited into. I'll be slowly expanding the Alpha, upgrading folks to full membership; when you are upgraded, you receive an email notification and can begin to create your own Spaces.

Your Spaces: there has been a "Your Spaces" page for a long time, which lists the Spaces that you own. It now has a second column, showing the other Spaces that you are a Member in. To manage this, we now have a first-class notion of Space Membership -- I expect that to grow over time.

Deprecating "Space-Specific Users": this mechanism was invented for the Wedding Space, and was basically a concept that you could invite anybody to use your Space *without* being a proper Querki user. As one of these users, you could access the Space *only* through the invitation link you were sent; you didn't have a login. It had a disastrous number of edge conditions, and in general I've written it off as a bad idea. One side-effect of the new changes (indeed, just today) is that the RSVP invitations for our wedding are now dead. That's a bit sad, but I think necessary: it was far too much work to support that weird code. So for now, using Querki, even as a guest, requires an account. (For write-access, anyway -- public pages are still public.)

Spaces and Identity: a subtle but important change -- Spaces are now owned by Identities, whereas originally they were owned by Users. Once I thought it through, I realized that the old way wound up leaking Identity information inappropriately.

This reflects a general design principle: as a User of Querki, you can potentially have any number of distinct online Identities. (Matching various email addresses, social networks, and so on.) In principle, we will be trying to keep these distinct, and at least making a good try at not leaking information between Identities -- I won't swear that it'll never happen, and I don't recommend using multiple Identities in the same User if it's a matter of life or death, but we're going to make a much more sincere effort than most systems do.

Names vs. Handles: finally got the distinctions straight here. An Identity may have both a name and a handle. The "name" is how you are displayed ("Justin du Coeur"); the "handle" is the unique identifier for you within an Identity Provider ("jducoeur"). Both are optional. In the medium term, I expect handles to generally be a paid-user perk -- they won't be as central as in LJ, but will be convenient in some ways. (For instance, your Spaces will be identified by your handle.)

Owners and Permissions: for the time being, only the Owner of a Space is allowed to set the permissions on Things (the Who Can Create/Read/Edit properties). Again, we'll eventually allow you to delegate this, but I'd rather err on the side of safety to start. This is also the camel's nose in the tent of "column-level security" -- eventually, it will be possible to limit the access to particular Properties. (Very much a power-user feature, which I expect to not even be visible in the standard-mode UI, but I suspect the hardcore programmers will enjoy it.)

returnTo: a little detail, but one that should make everyone's lives easier. If you try to do something, and get bounced to the login screen because you aren't logged in and aren't allowed to do it, it should now generally return you to what you were in the middle of once you log in.

Generalized the __display parameter__: those of you who have been following along at home may remember the syntax [[My Link -> ""__Link Text__""]] as a way to show a Link with the specified Link Text. This has now been generalized, at least in principle. We're not doing anything with it yet, but I suspect we'll reuse the same concept to enable, eg, date formatting. In principle, any Type will be able to have a display-template parameter using this approach.

Massive code refactorings: there's an awful lot more -- suffice it to say, I probably spent two weeks simply on necessary code cleanup. A lot of stuff hasn't changed, but works a lot more cleanly now.

What's Next

This is just a Release Candidate -- I believe it's feature complete, but there may yet be ship-stop bugs. (Indeed, I found several this afternoon, with the result that RC2 is actually already live.) I'm going to spend the next couple of days mainly focused on testing and debugging.

But barring any major crises, I expect Alpha to go live next week. That's strictly friends-and-family for the moment (mainly for legal reasons), but if you're interested in getting involved with the Alpha soon, comment here or drop me a note. I look forward to hearing what y'all think. (And am braced for the enormous number of bug reports that are going to flow in...)
Tags:

  • 1
1. Nice!

2. "if you're interested in getting involved with the Alpha soon, comment here or drop me a note" -- Interested! (Which you knew already, but just to put a reminder in a place you're checking.)

3. Names vs. Handles

Both concepts look very useful! I will note that you're using "Name" to refer to what I would call a handle, a la BBS handles or CB radio handles.

(I'm not sure exactly what I'd call what you're referring to as a "Handle". Identity? Canonical name? ID?)

Interested! (Which you knew already, but just to put a reminder in a place you're checking.)

Yep, but good to get confirmation. You're pretty much next on the list (having gotten Aaron up and running yesterday, and smoked out a few bugs along the way) -- expect an invite early next week. Actually, I'll probably invite all the Poker regulars, but you're first on the list for getting upgraded to full-user status. (With laurion probably next, if he'd like.) By the middle of next week, I'm going to want to begin revisiting the conversation about features you need for your projects.

3. Names vs. Handles

I figure that "name" is relatively self-explanatory, and means roughly what people will expect. Indeed, in the majority of cases (in the long run), I expect it to be derived from someone's social network account, and to simply be their wallet name. (Unlike the social networks, though, I have no plan to enforce that.) Unlike handles, names are simply display text, and can contain arbitrary strings. (Which does reminds me that I should test that that's bulletproof against XSS attacks -- another test for the list.)

"Handle" is less obvious, but seems to be the most common online term for "a short but human-readable unique identifier for a person". It is *not* the same thing as ID: not everyone will have one (like I said, it's going to eventually be a paid-user perk, with early users grandfathered in), and it is intended to be comprehensible in the same way as an LJ handle. Every Identity *does* have an ID (just like any other Thing in Querki); that will be used in cases where someone doesn't have a handle.

I don't expect handles to be a huge deal -- they will mostly show up in URLs, frankly. You'll note that all of my Spaces begin "http://www.querki.net/u/jducoeur/SpaceName": the "jducoeur" in there is my handle. If I didn't have a handle, it would instead use my OID (a seven-character unique alphanumeric beginning with a period). That's why I decided to make them a "perk" -- they're a limited resource, and not actually *necessary*, just nice to have.

Anyway, "handle" is definitely jargon. But it's jargon that seems to be in semi-common use, so I figure it's better than just making something up...

You're pretty much next on the list (having gotten Aaron up and running yesterday, and smoked out a few bugs along the way) -- expect an invite early next week. Actually, I'll probably invite all the Poker regulars, but you're first on the list for getting upgraded to full-user status. (With laurion probably next, if he'd like.) By the middle of next week, I'm going to want to begin revisiting the conversation about features you need for your projects.

Cool. I'm not going to have much time to actively play with it between now and Thanksgiving-ish - mid-November is BGG.CON, and I'm way behind in prepping prototypes for that - but I should have cycles for discussing features / use-cases.

Okay, sounds good. On my near-term to-do list is refreshing my memory about our previous conversation of your priorities...

I feel the same way on the name/handle divide, and thank you for bringing up the CB and BBS examples. In both cases you have a 'Handle' which is actually your nickname or use name, which is separate from any specific concrete identifier or canonical name. As opposed to Ham operators who always go by their operator callsign, a UID. CB Radio never really had a fixed ID, but I remember sometimes using license plates as a UID.

I am interested, but I'm not certain when I'll have time I can set aside to bang on it.

Interested, and I have experience finding bugs. I like to sit down and think like a user: "What stupid thing can I do that might make the system choke?"


Cool -- I've put you on the list, and will drop you a note as soon as I'm ready. Thanks!

(I'm sure that you will find *lots* to tell me about here...)

(hums a few bars from "50 Ways To Crash Your Java")

  • 1
?

Log in

No account? Create an account