Looks like we are going to need a functional wiki for the new album. I have more time to work on it if we can decide what we want to do with it.

There was some pretty good discussion for a while and then it stopped -- what remains to be decided?

Lots. I think a major part of the problem is that we were thinking about a full system that will support everything we need right off the bat, when what we really need is an easily expandable system. I'll see if I have some time this weekend.

Easily expandable is good. Everything we need may not turn out to be everything we need.

Also, a good implementation is always better than an outstanding concept.

Hmmm, I was worried about how we're going to get the wiki set up with editing support in one weekend, because that means not only writing the display and editing code and translating current data to that format, but also writing authentication code and testing it.

But then it occurred to me: why not let someone else do the authentication?

http://openid.net/wiki/index.php/FAQ

I'm still investigating this, but from the looks of it, I could skip worrying about password security. The user database for now would just be a name (like "Doctroid") paired with an URL at LiveJournal or another OpenID service (doctroid.livejournal.com) and all our website would do, for now, is ask LiveJournal if there's such a person, if that person is logged in, and if interrobangcartel.com is authorized to know.

At a later date, once other stuff is working, we can look into building an OpenID server into the software.

I am a big fan of starting with a simple implementation and then refactoring as I go to make things more flexible and expandable.

Let me know what I can do. I am pretty good at XSLT if you need it. I am happy to work on UI stuff. Unfortunately my Perl-fu is still pretty weak.

I finally got a chance to really read carefully and digest the plan. It looks really good! I can see the system and how easily it can be expanded to new types of information.

I am thinking that some utility to help work on the xml files might be useful. I could certainly generate some of the xml from the song files. Let me know if this would be useful.

I'm slow responding to this because I immediately thought of some tasks that could be done, like generating xml from the song files. But this required verifying I had a structure that could translate back and forth correctly, and so far the tests are negative, although I'm getting closer to the correct format.

And the other thing I thought you'd be excellent for was starting work on the login pop-up for the GUI, since you've already made a demo. I'm thinking we need something that matches the third row on this page:

http://netmesh.info/jernst-files/openid/login-dialog.html

We'd change the colors, of course, and the OpenID box would be the default... and the toggle would be temporarily disabled.

This pop-up should appear when you click a login link below the logo, which would be in a box in the upper left-hand column. After login, the link text would change to the user's name and the link would pop up a user admin box instead, which would give you a log out link (and some other stuff, but I don't know what yet.)

>>8
This looks pretty doable. I will play with...

I have a start on the login dialog, visually anyway.
http://ibc.spaceroom.org

We need to work out the logic for what should happen when the user hits the button. Can we do the login without having to refresh the page? I guess it will depend on the OpenId system.

Perfect look! We'll add the OpenID logo later, and maybe change the colors to the garish orange and yellow later, too. I'm still thinking about that.

We should be able to log in without refreshing the page. There's something called immediate mode, intended for AJAX websites. I'll read up more on how this works. But basically, if the OpenID server wants verification, another window (not a pop-up) should open on the URL returned by the server (LiveJournal's login page, for example.) When the user logs in and the server sends the ok message, the pop-up on our website should close and the logo area should change to reflect that the user is logged in. In fact, I'm thinking the user's name should appear superimposed on the logo.

I thought a bit about the user admin box, too. It should pop up when the user clicks on the logo or on a "preferences" link under the logo (which only appears if a user is logged in.) It should have tabs in the pop-up labeled "user", "page", "forum", and "site", but only the tabs a user has access to at the moment would be available.

The user tab should contain:

• an editable text box with the user's name in it;
• a box with the OpenID in it, with a logout button next to it;
• boxes for optional contact info (website, email, IM), with a "make public" checkbox.
• a help link, which goes to context-specific help.

I'm not sure what else, but that's good for a start.

I'm thinking that

I got the logo in the edit box. I was just missing some CSS.
If you have some links to OpenID I can read up on that would be cool.

The FAQ one the OpenID Wiki should be a good place to start:

http://openid.net/wiki/index.php/FAQ

Hmmm, that logo still isn't showing up.

Oh, wait, I should mention which Perl modules I was looking at specifically. I think this is the only Perl module for OpenID that doesn't require SQL:

http://www.openidenabled.com/openid/libraries/perl/

Also, you might not have to worry about the code too much, because I was looking into using CGI::Ajax, which might write the code for us:

http://search.cpan.org/~bct/CGI-Ajax-0.697/lib/CGI/Ajax.pm

... but on the other hand, CGI::Ajax only gives an example where it inserts code in the <head></head> section of HTML you give it, which is not going to work with PerlHP. I'm trying to determine if show_javascript() is the way to send the code to a PerlHP header section.

That's odd. I can see it under both IE and Firefox.

It was apparently a cache thing. Shift-Reload did the trick.

Anything else I can work on?
I wouldn't mind starting to look at some XSLT. If we can sketch out the rough structure of the page and how we want to transform the elements that would be a good start.

I can think of a couple of approaches. One is to create small XSLT files for each of the XML file types that convert into HTML fragments. Then a PERL page template could assemble the different parts with a number of small transforms. (With the divided nature of the files this probably makes the most sense).

If I could get samples of each of the files I could start to define schemas for each one and create some reference documentation. Then we can define the individual transforms and I could work on those.

Let me know what works best.

Unfortunately, I'm in the middle of ten billion things right now, so I'll get to this as soon as I can. If I understand you right, I agree that the XSLT files should create HTML fragments that the Perl code assembles into parts. However, they aren't quite linked to XML file types, but to data and media types. There's a main info box template for each of the media types (artist, album, song, plus "default",) an image box template for each media type, and templates for things like the tracks tab and the credits tab. Anything where the data is assembled from XML by the script, as opposed to the linernotes tab, which just loads a text file and translates it with Markdown.

When I'm done with the big reading/reviewing crunch and the convention this weekend, I'll clean up some of my documentation and get you some sample files.