kaberett: Overlaid Mars & Venus symbols, with Swiss Army knife tools at other positions around the central circle. (Default)
[personal profile] kaberett
Hi all!

I've just had a quick chat with [staff profile] mark following yet another support request about a GUI for the photo hosting system which does actually exist but is pretty bare-bones and currently undocumented.

Mark is comfortable that with a few UI tweaks it could be added to the main menu (Organize --> Manage files, or similar) in order to be discoverable.

The big thing is "have the HTML for embedding an image provided anywhere other than immediately after uploading it". At this stage adding more features/functionality is not on the cards (unless you're volunteering!), but in the spirit of doing a relatively quick UI polish, is there anything else you'd like to see?

I'll be filing an issue in a week's time, and hopefully we can get UI tweaks out in the next code push...
[personal profile] pinterface


The present config system is ... non-ideal. It should be better.

Problems / Pain Points

The existing config system is all-or-nothing: if you want to tweak one thing in config.pl—$USE_ACCT_CODES or @SCHEMES, say—you have to copy the entire thing, and will no longer get tweaks made to the base config.

As you might imagine, this makes upgrading painful. "Oh, they added an option and ... now it's all broken because I don't set it."

The existing config system also fails to compose. While it loads three config files—config-private.pl, config-local.pl, and config.pl—it only loads one of each. If you clone, say, dw-nonfree into ext/, it will load config-local.pl from that. Unless you already have your own config-local.pl in ext/local, in which case it won't use nonfree's at all. So even though you only wanted to make one or two changes over the baseline, now you're stuck merging all three config-local.pl files manually.

And just forget about adding bobs-awesome-dw-plugin. I don't know if anything beyond dw-nonfree exists, but hey, maybe at some point.

It also brings up the question of what config variable goes into which file? @SCHEMES and @LANGS are pretty darned site-specific, but they're in config.pl. $HOME is set to the LJHOME env variable in config-local.pl, but when are you ever going to change that? (In fact, things are likely to break if you ever did!)

Good Things

One of the nice things about the existing config system is that it is pure Perl, bringing with it all the flexibility that provides. (Though some might argue that a turing-complete configuration file is also a drawback.)



Let's move to a Debian-style conf-available/conf-enabled split system, where all config files are loaded, and then merged.

Technical Details

Directory Structure

Similar to the existing structure, except the provided config files would be placed into directories called something like "conf-available" or "conf.d". Config files would be loaded, in lexicographical order, from a single "conf-enabled" directory, which is populated with symlinks to the actual config files.

  • etc/conf-available/
    • private.example.pl
    • local.example.pl
    • defaults.pl
    • down-for-maintenance.pl
    • schemes.pl
  • ext/local/conf-available/
    • private.pl
    • local.pl
  • ext/dw-nonfree/conf-available/
    • nonfree.pl
    • schemes.pl
  • etc/conf-enabled/
    • 00-private.pl → $LJHOME/ext/local/conf-available/private.pl
    • 10-local.pl → $LJHOME/ext/local/conf-available/local.pl
    • 50-nonfree.pl → $LJHOME/ext/dw-nonfree/conf-available/nonfree.pl
    • 50-free-schemes.pl → $LJHOME/etc/conf-available/schemes.pl
    • 50-nonfree-schemes.pl → $LJHOME/ext/dw-nonfree/conf-available/schemes.pl
    • 90-defaults.pl → $LJHOME/etc/conf-available/defaults.pl

Config Files

Config files would each return a hash of values. It would be the responsibility of the config system to merge them all together appropriately. Essentially, this would be done in the same manner as used by Config::FromHash. However, because a number of config values are defaulted using prior values, it would be necessary to provide a dynamically-scoped variable containing the config-as-loaded-thus-far, to support that (hopefully that will be made clear by the examples).

# ext/local/conf-available/private.pl
    DOMAIN => "example.dreamhack.net",
    DBINFO => {
        # ...
    # ...
# ext/local/conf-available/local.pl
    IS_DEV_SERVER => 1,
    SITENAME => "My Awesome DW Site",
    # ...
# ext/dw-nonfree/conf-available/schemes.pl

use DW::Config::FromHash qw( $CONF );

# Manually append schemes
    { scheme => 'neato', 'title' => 'Neato' },
    # ...

    # ...
    # Or, a potentially abstracted way to add things
    add_SCHEMES => [
        { scheme => 'neato', 'title' => 'Neato' },
    # ...
# etc/conf-available/defaults.pl

use DW::Config::FromHash qw( $CONF );

my $www = "www.{$CONF->{DOMAIN}}";
    DOMAIN_WEB => $www,
    SITEROOT => "http://$www",
    # ...

Merging, and Post-Merge

As mentioned, the config files would be loaded and merged in a manner similar—if not entirely identical—to Config::FromHash.

After the config files are loaded and merged, it would be the responsibility of the Config system to populate all of the appropriate variables in the LJ and DW packages.


Much simpler to use! You can create a file to override a single value and re-use the existing configuration for everything else. And it works more like you'd expect if you're used to conf.d directories.

Easier manual testing. While automated tests are obviously best, if you need to test something works without and without X service, you can add and remove a symlink to a conf file enabling that service, restart apache, and poke at things.

Paves the way for better support of plopping things into ext/ and having it work. No more "copy these config values into your existing file", just symlink and go.


Harder to fully comprehend. It's more files floating around, more state to keep track of (-available, -enabled, symlinks galore!).

It's dramatically different, and converting an existing installation would be a pain. (But see below.)

Config reloading (see start_request_reload in Config.pm) is more involved. Far more files to stat, and a lot more work to reload them all. One possibility would be to drop config reloading: how often are config changes made that don't involve a code change that would necessitate restarting apache anyway? ($SERVER_DOWN maybe? But that could easily be converted into a flag file check.)

Not Breaking Existing Installations

It would be preferable to avoid breaking existing installations. I think this is possible: after performing the above, follow that up by running the current config system. While that does mean having multiple config systems running, it gives people time to migrate at their leisure, rather than breaking things immediately.

After some time with the new system, we could then add deprecation notices in the event the old system is still in use. After sufficient time has passed, we could then eliminate it entirely.

Or, we could treat it like ripping off a band-aid and break things and be all "hey, sorry about the one-time pain but we're eliminating the smaller pains you almost never have anyway because really how often do we change these things?".

Why Not Just //= Everything?

One thing you might be thinking is "Well, why not just //= everything in the default config*.pl files?

That's definitely much easier to implement! And it brings with it many of the same benefits—people could simply add their overrides to config-local.pl or config-private.pl and never need to create or edit a config.pl (4f8258a does that for @LANGS, it's totally viable).

One of the drawbacks of that approach is that it requires a developer updating the default config*.pl files to never make a mistake. Accidentally used = instead? Tried to use //= to set a list, even though //= only works for scalars? Well, now things are quietly broken in other people's installs. By automating the merge behavior, we can largely avoid that. Whether the additional complication of a split config brings enough benefits over conditional sets to be worthwhile is another matter.

Thoughts? Questions? Alternative proposals?

brainwane: My smiling face in front of a brick wall, May 2015. (Default)
[personal profile] brainwane
[personal profile] marnanel has started working on an Android client for Dreamwidth. Here's their care-and-feeding-of-marnanel post, and [community profile] dwim is the community about this Android work specifically. Their welcome post asks some questions and invites discussion, about UI, caching, whether anyone would like to help, and more.

I'm not involved with the work -- just signal-boosting. I know [personal profile] marnanel to have experience with writing mobile applications. In fact [personal profile] marnanel was the maintainer of Joule, a mobile LiveJournal client ([community profile] joule).
kaberett: A sleeping koalasheep (Avatar: the Last Airbender), with the dreamwidth logo above. (dreamkoalasheep)
[personal profile] kaberett
These are not-as-quick-as-I'd-like-but-definitely-dirty, and are based on our previous discussion about specification and workflows. It's been a while since that post, so I'm making this one for the pictures; in summary, there are two options for how to go about managing this.

In all cases, I should have used "Community control" rather than "Additional Privileges" but I... absolutely could not face going back and editing everything again when I realised, sorry. And in all cases I haven't provided complete lists of privileges/privilege bundles -- those exist in comments on the previous post, and will get put into the final composite spec properly. (I... am being pretty slapdash about this, sorry, but if I try to get everything Just Right at this stage what will actually happen is I'll spend the next six months hyperventilating about how y'all will kick me off the project if I use the wrong font and nothing more will happen, so this is a sketch for the idea of the thing, sorry.)

Also in all cases, there should be another header row under "non-members", but I ran out of steam, see above, sorry.

Option 1: tickbox matrices as far as the eye can see

This is the option laid out in the last post: replace "Administrator" and "Moderator" checkboxes with a "Community Control"/"Additional Privs" box, and an Additional Privs/Community Control page with a bunch of tickies (with "Administrator" acting as a master ticky, though that isn't illustrated here).

Read more... )

Option 2: Define community control roles

This was suggested in comments on the previous post, as a way of creating custom roles/priv bundles as required by the community. In addition to the Additional Privs/Community Control link, /communities/list would then also have "Manage Roles" as an option. Which members were displayed on the Additional Privs/Community Control page would again be controlled by the checkbox so labelled on the Edit Community Members page, as for option 1.

Read more... )


Priv bundles will need explaining. This could happen on-page, in dedicated FAQs, or both. (Probably both.)

Your thoughts?

Comments welcome, but have an easy poll:
Open to: Registered Users, detailed results viewable to: All, participants: 27

Which workflow do you prefer?

View Answers

Option 1: matrices as far as the eye can see
5 (18.5%)

Option 2: roles-based community controls
20 (74.1%)

Something else, which I will explain in comments
2 (7.4%)

Thanks heaps for your patience, folk!
kaberett: A sleeping koalasheep (Avatar: the Last Airbender), with the dreamwidth logo above. (dreamkoalasheep)
[personal profile] kaberett
This outline is based on previous discussion about how this might work. Currently the best option seems to be a pretty unwieldy matrix: if you've got further suggestions please do let me know. Because it's unwieldy, the rest of this is going under a cut.

Read more... )

Points for discussion

  1. This is going to be enormous. Suggestions for how to minimise scrolling?
  2. It is possible to duplicate settings between the various pages mentioned in section 1 and the proposed new privs management interface; however, I suggest that's prone to error and confusion and might therefore be better off not happening.
  3. I'm not convinced that we actually want the last two tickies on my big list there; I'm not convinced there's any point in letting people who aren't administrators have the ability to grant and revoke administrator status :-p
  4. Are there privileges missing off that list that you can think of? Are there points you think should be subdivided? (I am thinking particularly of edit/delete/flag posts made to the community, and un/screening comments: I can see a scenario in which you want people to be able to screen comments until someone with more seniority comes along and drafts a response and only then unscreens it, to minimise flamewars; ditto un/freezing.
  5. Terminology: "Additional Privs" is a placeholder; suggestions for something clearer/more user-friendly enthusiastically welcomed.
kaberett: A sleeping koalasheep (Avatar: the Last Airbender), with the dreamwidth logo above. (dreamkoalasheep)
[personal profile] kaberett
Community admins frequently want to delegate specific tasks to specific users; for example, I'm generally responsible for tagging [site community profile] dw_suggestions but for no other tasks; it's common in RP communities for a particular user to be designated the "coding admin", responsible for layout and styling.

In the case of tagging, there have been several suggestions about making tagging permissions more granular and for that matter more obvious to the user. However, even these suggestions end up breaking down permissions to a choice of: admins only, entry author and admins, members only, anyone.

In practice this means that either (a) work gets concentrated on a relatively small number of people who aren't necessarily best placed for the job, or (b) admin status gets given to a large number of people, none of whom need all the permissions they've been granted. It would be much better if it were possible for admins to grant specific permissions to specific users as required, rather than the broad-brush systems currently in place.

The difficult (as ever!) is designing a suitable system it in such a way that it avoids being overly confusing and leading to somebody giving somebody else powers that they didn't mean to delegate, and avoids decision fatigue.

The purpose of this post is to hammer out how more granular permissions might work, both back-end and front-end (in terms of what the options presented to community admins look like). Please do drop thoughts/suggestions/requirements/etc in comments; discussion positively encouraged.

ETA wiki page that triiiies to provide a list of what all community maintainers do
darael: Black lines on a white background.  A circle, with twenty-one straight lines connecting seven equally spaced points. (Default)
[personal profile] darael
Dreamwidth's APIs are poorly documented (people basically have to work off docs for old versions of LJ's APIs). They're also missing key features, like comment handling for more than backups.

I've been told there have been "some internal conversations about deprecating the XML-RPC API -- keeping it for backwards compatability, but moving to a much more modern second-gen API", but that nobody has had both the time and the inclination to work on designing such a thing.

Well, this is me, volunteering. To that end, I'm looking for input on what exactly such a new API needs to provide, and whether there's a preferred underlying technology to build on (exempli gratia, stick with XML-RPC? Change to SOAP? Use JSON? RESTful or not? et cetera). What I'm getting at here is that I'm entirely happy to take point, as it were, and to make decisions (especially where there's little or no consensus and someone has to make the call), draw up specs, write docs, and so forth, but the result is highly unlikely to be a really useful API unless I get input from more sources than my own experience and looks at the code.

At this stage, therefore, I want everything you, the reader, have to say on the subject. Use cases especially.

pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
$TRUST_X_HEADERS is a configuration variable you should set to true (1) if you're using proxy you control and trust (eg, perlbal), so you can retrieve the real (external) source IP address of incoming requests, instead of seeing them as coming from or the IP address your proxy/load balancer/whatever runs on. By default, it's 0, but for dreamhacks and other development hosts, that default isn't practical, so instead of making it default to 0 (with a commented-out line in etc/config.pl to change it to 1), I would make it default to the value of $IS_DEV_SERVER if not defined, with commented-out lines in etc/config.pl to force it to either 0 or 1.

This shouldn't affect production servers, who likely have IS_DEV_SERVER set to 0 and TRUST_X_HEADERS set to 1 already, but it might affect production servers, if any, with unexpected configurations, and the change may surprise developers who didn't set TRUST_X_HEADERS explicitely, so I'm throwing this for discussion here in case I missed some pitfalls, or if there's a way to make it better. I'm also opening a bug linking here, so whatever the outcome of the discussion is, it doesn't fall through the cracks.
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
So a while back I did an open card sort for people to help us reorganize the Account Settings tabs. The project never went anywhere, because there was zero agreement among the answers: usually when you do an open card sort, things will fall into two or three different major sets of buckets and you can work from there, but this one was all over the place and I despaired at ever doing anything with it.

The settings overrun has gotten much worse since then, though, and it's starting to be more urgent to redo them. I've taken a first stab at what I think is a logical grouping; the items inside each tab category are not organized in any way (just reorganizing the order things are listed in will make a lot of difference, I think) but this is my first pass at redoing the groupings.

The major changes (in addition to reordering the tabs themselves) are the consolidation of the Account and History tabs and the Mobile and Other Sites tabs, and the splitting of both Display and Privacy into Journal vs Site; this means we keep the number of tabs constant but there are fewer items in each tab. That, I think, will take care of 90% of the "auuugh options overload", although some of the things are very borderline as to which tab they should go on. (But it's not like it's any better now.) I've included both the label that's displayed to the user (although when I started out I was renaming some of them to be more clear) and the name of the settings package in the code.

Thoughts? Major objections? Once we go through these I'll work on reordering the settings within each tab, and put up a version on my 'hack for people to see in action.

proposed new tabs/organization )
pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
Can someone who groks JS better than I do check whether http://code.livejournal.org/trac/livejournal/changeset/20330/trunk and http://code.livejournal.org/trac/livejournal/changeset/20331/trunk is a browser-based syntax-highlighting S2 editor? (Or part of one, maybe?) I kinda want to submit a suggestion for something similar, if it is, but I can't do that without having some idea of what it does.

Bug 2886

Oct. 9th, 2011 04:41 pm
randomling: A wombat. (Default)
[personal profile] randomling
So I'm working on Bug 2886, and for most of it I have a working patch. (Back end, at least - and the front end looks like it will be fairly easy.)

I have one question on the spec here, which I wanted to open out to the wider community.

We're allowing title attributes (ie: hover text) for the user-defined links that show up in the sidebar. Showing them on links was, once I had much hand-holding through the codebase and figuring out what in hell I was doing, not that hard. However - that particular widget also allows users to define headings (by simply plugging in a title and no link).

It turns out it's a much harder problem to figure out how to allow hover text over the headings without breaking everything else, 'cause that refers to the way all the headings for the modules are printed, and hover text is (on most of them) an attribute that will never get used. So it's going to end up with passing a lot of empty strings back to the appropriate function, if I implement this.

So my question is: should I implement the possibility of hover text over headings? What do you guys think? Is that worth the time and effort and rejigging of the codebase to allow it?

It might perhaps be useful to have such an attribute available, should we decide to make more hover-text-related changes in the future.

Anyway - please let me know your thoughts.

(Also, I'm feeling anxious that I have been confusing or unclear. Do let me know if there's anything you need me to clarify or explain further.)
pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
Currently, Dreamwidth supports (somewhat half-heartedly and clumsily) sites with user-visible URLs that look like http://www.example.com:6809/, and I've been wondering about a few things:

1- How many sites running Dreamwidth code actually use that feature? How many couldn't run without it?

2- If you're considering running a Dreamwidth-based site or are working on one, would it or does it need that feature to run?

3- If neither of the above applies to you, do you find that feature important, pleasant, infuriating, or neither? Why?

(Note: I'm not speaking of hosted Dreamhacks here, since even those that use another port internally are mapped to port 80 using Perlbal.)
kareila: (Default)
[personal profile] kareila
This recent post brought to my attention the fact that it really ought to be simpler for sites using DW code in production to easily keep up with stable milestones of DW development, without having to look through all of our repositories for the most recent milestone tags. Besides, the milestone tags are tied to code pushes on dreamwidth.org and not necessarily an indication of stability!

I propose the following mechanism:

1. Add a "stable" tag to all of our shared repositories. We already do code freezes where we only put in changes to fix bugs that are uncovered immediately after a code push. When the code freeze is lifted, move the "stable" tag to the most recent milestone and leave it there until after the next push/freeze cycle. For example, the most recent cycle would have moved the stable tag from 0.21.2 to 1.0.1 once it became clear there would be no 1.0.2 needed.

2. Add a new site config parameter (something like DW_STABLE) that indicates whether a site is only accepting our "stable" changes.

3. Change the behavior of -update in bin/vcv to only update as far as the "stable" tag if DW_STABLE is set.
wyntarvox: (Default)
[personal profile] wyntarvox
I am working on bug 3479. Basically, the suggestion came in to have subsequent notifications for edited comments simply have a message saying that the comment was edited, the time, and the reason, rather than repeating the body of the comment as they currently do now.

I set out to make edited comments an event on its own (well, a sub-event of LJ::Event::JournalNewComment). Notifications are built on-the-fly using the live comment object, so adjusting the display for an edited comment to only have the time/reason, will make the original notification do the same. [personal profile] fu and I bandied about the idea of using the event time and either compare it to the edit time or the original comment time, but both of these had drawbacks.

Event vs. edit time meant only the last notification of an edit would be the short version. Event vs. original comment time meant we'd have to have an amount of room-for-error between the comment being posted and the event firing, which defeats the purpose really. A big reason for the suggestion was to prevent multiple identical notifications when someone posts a comment, notices a typo, edits, all within our window of room-for-error.

So, we came back to it being necessary to have this as a separate event. However, that also means needing a separate subscription for comment edits. There are a few options:

  1. Have a separate subscription for comment edits (maybe people would like this and don't care about being notified re: edits?)

  2. Special-case comment edits to piggy back off subscriptions for new comment edits

  3. Build something more robust to let any event piggy back off the subscriptions of another event

Thoughts, comments, direction? Please?
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
Coming back with another question re: service documents, which was brought up in the comments to my earlier entry.

Is it better to consider the service document on a per-journal, or on a per-account basis? The service document is a URL you enter for your client to discover which URLs to use to post to a journal or a community.

I have seen two separate sets of suggestions, one that says to put the service document in:


which lists your journal as well as any communities you have posting access to.

The other train of thought says to to put the service document in:

And list only the collections (entries and eventually media such as images) that you can manipulate with that particular journal.

In both cases, entry posting will under journal space, such as http://username.dreamwidth.org/interface/atom/entries/1, etc.

I'm going back and forth on this one. I currently have the latter implemented, but am beginning to talk myself into the former. Before I tweak my code, though, I'm interested in hearing any more informed opinions on which option is the more standard.

On that note, the atom interface code is up on my public dev server, which is open for testing for anyone interested in trying it out with any clients you use. And if someone can point me to your favored client or service which uses APP, I'd like to try testing that on my own.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
I've been working on updating our implementation of the Atom Publishing Protocol, and have put up an entry discussing the new implementation.

Happy to hear any concerns! In particular, any huge objections to breaking it for clients used to the old verison of the atom interface? And thoughts on using the http://yourusername.dreamwidth.org/interface/atom, rather than http://www.dreamwidth.org/interface/atom? The former would make it easier to implement community support.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
Working on some long-overdue updates to the checkfriends protocol mode.

Changes not yet live on the site but should be for future code push, but here's the run down:

  • checkfriends no longer works. Instead, use checkforupdates.

  • required arguments to checkforupdates is only authentication information

  • optional argument lastupdate (in "0000-00-00 00:00:00" format). This is the last update time you have, from previous calls to checkforupdates

  • optional argument filter. This is the name of a content filter whose members you want to filter to.

  • return value: new: 1 or 0. 1 only if you pass in a lastupdate and there are new items since then. 0 in all other cases.

  • return value: interval: number of seconds before you can next check for updates. If you check before time expires, you'll get a cached value

  • return value: lastupdate: time someone last updated, in "0000-00-00 00:00:00" format

It's almost exactly the same as checkfriends; the only differences from the frontend are the name change, and replacing the mask argument with a filter argument because the trustmask is no longer relevant since we split up access and subscription.

ETA: Added preliminary documentation on the wiki.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
I'm looking for feedback on Bug 3170: Constant Namespaces in DW::Template.

Basically, right now our constants in .tt files can be found under email.*, site.*, roots.*, etc, and the more constants we have, the more likely it is that we'll accidentally have a namespace collision. So I would like to have all constants be under just the site namespace.

That is, instead of using:

We can use:

In some cases, it's longer, but the additional clarity should be worth the extra characters. (Plus it would also make it easier to avoid mistakes -- I found several instances of dw.* in the files, which are blank, but luckily cause no issues)

List of proposed new namespace )

I'd like to point out, in particular,
site.name = $LJ::SITENAME
site.names.short = $LJ::SITENAMESHORT
site.names.abbrev = $LJ::SITENAMEABBREV

which suffers from inconsistency/needing to be aware of the technical limitations.

An alternative:
site.name.site = $LJ::SITENAME
site.name.short = $LJ::SITENAMESHORT
site.name.abbrev = $LJ::SITENAMEABBREV

But that suffers from the problem that the most commonly used variable, site.name, becomes long/ridiculous/redundant.
kareila: (Default)
[personal profile] kareila
I appreciate all the feedback I got on my previous post. Here's my thinking based on the comments there:

Tag list: wait for the new update page. The LJ implementation looks pretty buggy anyway, judging from initial reports.

Tag search: yes, we should make a GUI the primary interface to tag search on our site. It should:

* support complex boolean operations
* use either a POST to avoid the URL parsing problem, or an entirely new URL format (since you can't bookmark the result of a POST), or possibly both
* allow you to search for tags in more journals than just your own, as a paid feature (which means it should be a site page like "Manage Tags", not a journal page)
* allow further refinement of results based on date range and/or security level, possibly even mood (yes, that has already been suggested elsewhere)

However, that should be a new bug (or several bugs), perhaps more accurately titled "Metadata Search" to complement the existing Content Search. It need not immediately replace the basic tag search we inherited from LJ, which was never so ambitious.

A codemerge from LJ, if possible, would close the existing bug (which came from suggestions) for fixing the basic URL search in the current syntax, with added support requested for using ALL as the keyword instead of AND (although we should allow both for compatibility). If our code has changed too much to merge, or if it proves difficult to take only that part of the change and leave out the tag list code, we could reconsider whether it's worth the effort - but compared to the "all that and a pony" spec outlined above, it seems simple enough.

I think this approach would give us a usable (if "ugly") short term solution with minimal effort for the most basic use case, plus space to plan for a better long term solution in the future.


dw_dev: The word "develop" using the Swirly D logo.  (Default)
Dreamwidth Open Source Development

March 2017

5678 91011
1920212223 2425


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Mar. 26th, 2017 05:21 am
Powered by Dreamwidth Studios