Dreamwidth Development

API wishlist?

2017-10-11T02:29:58Z

Posted by: momijizukamori

So my workplace gives us a chance twice a year to work on anything we want for a few days, work-related or otherwise, and I thought I'd use some of my time to actually get the new API into a state where we can make it live. With that in mind! What endpoints would you like to see implemented? We're making this Swagger/OpenAPI-compliant, so everything takes JSON as arguments and return JSON formatted data. Stuff already on the list to do or partially done:

/api/v1/users/{username} - GET, shows info about the user (specific info TBD; subset of profile, probably?)
/api/v1/users/{username}/icons - GET, lists icons
/api/v1/users/{username}/icons/{iconid} - GET, returns icon data
/api/v1/users/{username}/journals - GET, returns list of journals with write access.
-- for now, returns only user's primary journal
/api/v1/journals/{username}/accesslists - GET, list of access lists for journal
/api/v1/journals/{username}/tags - GET, list of tags for journal
/api/v1/journals/{username}/xpostaccounts - GET list of xpost accounts
/api/v1/moods - GET list of moods
/api/v1/commentsettings - GET list of allowed comment settings
/api/v1/journals/{username}/entries - POST new entry, GET list of recent entries
/api/v1/journals/{username}/entries/{id} - POST edit entry, GET specific entry
/api/v1/journals/{username}/files - POST new file
/api/v1/spec - GET, returns a description of the API

(Mark and D, as usual, get the final say - some stuff people want may end up being security/privacy risks in non-obvious ways)

comments

What does the file manager need before rolling out?

2017-01-02T01:46:40Z

Posted by: kaberett

Hi all!

I've just had a quick chat with 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...

comments

RFC: Config Yak Shaving / Bikeshedding

2016-05-13T21:44:22Z

Posted by: pinterface

Summary

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.)

Proposal

Summary

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
$CONF->{SCHEMES} = [
    @{$CONF->{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.

Pros

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.

Cons

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?

comments

Android (mobile) client

2016-01-13T13:52:45Z

Posted by: brainwane

marnanel has started working on an Android client for Dreamwidth. Here's their care-and-feeding-of-marnanel post, and 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 marnanel to have experience with writing mobile applications. In fact marnanel was the maintainer of Joule, a mobile LiveJournal client (joule).

comments

QuickReply error handling: choice of solutions

2015-11-08T13:01:56Z

Posted by: shortcipher

Issue #1622: AJAX quick* reply when you can't comment is unsubmittable - your thoughts please? (Sorry it got so long and wordy.)

comments

More granular community permissions: mocked-up screenshots

2015-09-26T15:41:15Z

Posted by: 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... )

Documentation

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:

View Poll: #16996

Thanks heaps for your patience, folk!

comments

Draft specification: more granular community permissions

2015-09-13T10:01:34Z

Posted by: 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

This is going to be enormous. Suggestions for how to minimise scrolling?
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.
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
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.
Terminology: "Additional Privs" is a placeholder; suggestions for something clearer/more user-friendly enthusiastically welcomed.

comments

Brainstorming specification: granular community permissions

2015-08-07T12:17:38Z

Posted by: kaberett

Community admins frequently want to delegate specific tasks to specific users; for example, I'm generally responsible for tagging 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

comments

On clients and APIs

2014-04-20T01:14:21Z

Posted by: 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.

Go.

comments

RFD: changing the default value for $TRUST_X_HEADERS on development servers

2012-04-07T17:13:47Z

Posted by: 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 127.0.0.1 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.

comments

first pass at redoing Account Settings tabs

2012-01-31T08:30:24Z

Posted by: 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 )

comments

JS-based S2 editor with syntax highlighting?

2011-10-15T13:12:29Z

Posted by: 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.

comments

Bug 2886

2011-10-09T15:48:51Z

Posted by: 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.)

comments

Use of non-standard port numbers in sites running Dreamwidth code

2011-05-25T17:38:56Z

Posted by: 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.)

comments

stable releases

2011-05-20T14:53:15Z

Posted by: 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.

comments

New Event and Related Subscriptions

2011-03-07T09:02:53Z

Posted by: 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. 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:

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

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

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

Thoughts, comments, direction? Please?

comments

Service Document?

2011-01-25T08:51:23Z

Posted by: 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:

http://www.dreamwidth.org/interface/atom

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:
http://username.dreamwidth.org/interface/atom

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.

comments

Atom Publishing Protocol

2011-01-12T04:55:14Z

Posted by: 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.

comments

Updates to "checkfriends" protocol mode

2011-01-01T05:15:41Z

Posted by: 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.

comments

Constants Namespaces in .tt files

2011-01-01T04:55:10Z

Posted by: 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:
email.webmaster
roots.site
site.name

We can use:
site.email.webmaster
site.root
site.name

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.

comments

LJSV-1068 redux

2010-07-24T07:43:59Z

Posted by: 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.

comments

LJSV-1068

2010-07-21T15:38:35Z

Posted by: kareila

LJ just unveiled two features I've wanted here but haven't known how to implement, which are a tag list on the update page, and searching for multiple tags using AND instead of OR.

For the first, am I to assume that the new update page will support this, so we don't need to bother with trying to patch the feature into the old update page? Or perhaps rather that the new update page won't support it immediately, but it will be such a radical change that we shouldn't even bother working on it until then? (I really want this ASAP, and it has appeared on "most wanted".)

For the second, should we roll our own fix adopting LJ's URL syntax, or attempt a codemerge? Here's the syntax for those who missed the announcement:

http://username.livejournal.com/tag/tag1,tag2?mode=and
http://username.livejournal.com?tag=tag1,tag2&mode=and

The URL syntax was what bogged us down on that bug, and this seems like a reasonable solution, plus it's what users of both sites will come to expect.

Links to our Bugzilla:

http://bugs.dwscoalition.org/show_bug.cgi?id=581 (for the tag list)
http://bugs.dwscoalition.org/show_bug.cgi?id=1585 (for multiple tag search)

comments

Desktop Client Proposed GUI

2010-04-08T05:05:44Z

Posted by: mrigeshpokhrel

hi all,

I designed a gui for my would-be application, kindly go through and make any suggestions or comments you seem necessary.

http://mrigeshpokhrel.dreamwidth.org/1184.html

regards,
mrigesh pokhrel.

comments

Template access to LJ::set_(active|dynamic)_crumb and LJ::need_res

2010-01-30T19:50:24Z

Posted by: pauamma

foxfirefey's let's keel BML ded (and eat its head) nudged me into TTizing the stats pages before they get too unwieldy. So (because that page uses crumbs) I'm looking at how to set a crumb in the template (which I think is the proper place to do it, since templates map better onto pages than controllers do IMO). The interface I'm thinking of (tentatively - I haven't actually tried this yet) is something along the lines of:

(something relying on RAWPERL, which is (and will likely remain) disabled, so filter/plugin it is instead, per exor674's comment below)

I'm also wondering whether to make it a filter (or something) in DW::Routing::Apache2 instead, but I don't want to make further work on it harder if I can avoid it.

Anyone has a thunk about this? (Specifically exor674 and foxfirefey, since they're leads on this, but not limited to them)

comments

More brainstorming on stats: payment stats

2009-12-25T20:41:02Z

Posted by: pauamma

So I'm still chipping away at bug 124, and I've reached:

* Number of payments in last 1d/2d/5d/7d/1m/3m/1y
-- broken down by which payment level/payment item chosen
-- xxx and divided into new payments vs. renewals
-- xxx and expressed as a dollar amount taken in during that time

Now the first thing to figure out is where and how payments are stored in the database, and whether (and how) I can use the stored data for my purposes.

Since I need to split data by what was ordered, I need to use shopping carts (table shop_carts, module DW::Shop::Cart), since that's where that information is. However, shopping carts don't tell me when payment was received, only when the cart was opened/checked out/whatever. For payment by check or money order, the difference could be substantial (several days to over 1 week), esp. if you want to wait for checks to clear until you record the payment. Since this is longer than the periods over which we want stats, it won't work, so I either need to base the stats on the order date instead of the payment date, or to use something else in addition to cart data.

It's tempting to use pp_trans (see DW::Shop::Engine::PayPal), but that's only for PayPal payments (as far as I can tell), so it won't work for that purpose, since there are no equivalents for other payment methods (credit card, check, money order). Plus, I just care when the payment was received, not how, so I don't really want to get into that, with the likely maintenance nightmare that would come when another payment method is added, or worse, when payment for a given cart may be split between methods (hello, gift certs).

So it looks like I need to add some data to shopping carts. All I need at that stage is a single timestamp for the last change of state, which could be indexed, which is nice (I can retrieve carts for which payment was received (state is PAID or PROCESSED - see $STATE_* in DW::Shop) in the last (mumble) days. For existing carts that won't have that timestamp, I can either set it from the creation timestamp or use other means, such as scavenging through pp_trans. I don't really need to keep a complete history of state changes, and I can't think of a use case for one (but then, I'm not an accountant, not a lawyer, and not a developer of financial/accounts receivable/ecommerce software).

Anyone wants to laugh at/tear into the above, or suggest alternatives or stuff I overlooked?

comments

Dreamwidth Development

API wishlist?

What does the file manager need before rolling out?

RFC: Config Yak Shaving / Bikeshedding

Summary

Problems / Pain Points

Good Things

Proposal

Summary

Technical Details

Directory Structure

Config Files

Merging, and Post-Merge

Pros

Cons

Not Breaking Existing Installations

Why Not Just //= Everything?

Android (mobile) client

QuickReply error handling: choice of solutions

More granular community permissions: mocked-up screenshots

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

Option 2: Define community control roles

Documentation

Your thoughts?

Draft specification: more granular community permissions

Points for discussion

Brainstorming specification: granular community permissions

On clients and APIs

RFD: changing the default value for $TRUST_X_HEADERS on development servers

first pass at redoing Account Settings tabs

JS-based S2 editor with syntax highlighting?

Bug 2886

Use of non-standard port numbers in sites running Dreamwidth code

stable releases

New Event and Related Subscriptions

Service Document?

Atom Publishing Protocol

Updates to "checkfriends" protocol mode

Constants Namespaces in .tt files

LJSV-1068 redux

LJSV-1068

Desktop Client Proposed GUI

Template access to LJ::set_(active|dynamic)_crumb and LJ::need_res

More brainstorming on stats: payment stats

Why Not Just `//=` Everything?