Micah
I put up a "blog post with some ideas":http://blog.obsidianportal.com/?p=1330 about how to use the API to make DST creation and editing much easier. It's by no means the one and only way to approach it, just my first thoughts.
I'd love for someone to step up and create an actual desktop application to handle this. If you're interested, please speak up and let's figure out a way to make this happen.
Some references:
* "The blog post":http://blog.obsidianportal.com/?p=1330
* "The DST API page":http://help.obsidianportal.com/faqs/api/api-dynamic-sheet-templates
Comments
C# is my specialty, so I would be speaking from this reference. Probably what I'd do is let people use their own editors to edit the HTML template/CSS/Javascript... no need to reinvent the wheel there... just have a hosted browser window that watches for updates to those files and refreshes it's view... where the view is the dev kit's wrapper HTML with the CSS and template from the user injected into it.... probably have spots for the user to enter the slug etc so the template will work.
Then it's just a matter of a simple UI for downloading / uploading the files via the API, which shouldn't be too hard. I think, by keeping it simple, it can be pretty robust and easy to use. Get fancy, and things get buggy and take a lot longer to build.
I would imagine this is doable in a weekend or a few weeknights for someone with some free time (something I am notably lacking... though I may give it a try anyway... been wanting to poke at the API some to get some ideas about how it might be used).
This is just one idea, and I'm definitely open to others. I would like, however, to remove the dev kit as much as possible. It's going to get out of date, I just know it.
Also, there is no issue with having in-development html, css, or javascript in the DST. That's what the review process is for. Having the in-development code live on the site allows you to see exactly what it will look like for a character, which is really the end goal anyway.
Doing a little searching shows that OAuth is not so great with desktop / mobile apps. See more here: "http://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps":http://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps
Hmm, that really sucks, as I imagine that a lot of the API apps will be mobile or desktop apps. Crap, gonna have to rethink things a bit...
At some point in the process, inevitably, someone has to trust someone. In this case, either users have to trust application developers not to steal their credentials, or application developers have to trust anonymous malicious hackers not to decompile their code and impersonate their applications. The hackers may represent the less common threat, but on the whole, I think the application developers are the more trustworthy bunch there, and doing simple authentication through the application has the added advantage of being, as the name implies, simple.
I'll grant that it's not perfect for mobile and desktop apps. There will never be a way for us to verify that they are who they say they are. Someone can grab their key and secret and use that to make requests in the name of the app it was stolen from. The OAuth people recommend not trusting the consumer key and secret and using it only for statistics gathering. That's our plan. We won't go around invalidating keys in order to stop hackers. We'll have to be smarter than that.
On the upside, even if we cannot trust the application to be who it says it is, OAuth still allows us to protect the users. An app with a stolen key and secret would still need to get the user's access token and secret in order to make requests on their behalf. Likewise, a user can decide to revoke access to an application at any time, and they can revoke selectively. With most simple schemes, like an API key, the user would have to revoke access to all apps, and still has the copy/paste issues of OAuth. Worse still, if they used username/password, they would have to change their password if they ever wanted to revoke access to an app.
For now we're going to push forward with OAuth, but this is the kind of feedback that we want. There's still time to switch to something else, and if everyone truly hates it, we'll definitely listen.
Web apps - Normal OAuth flow. Redirect users to our OAuth authorize page, when they accept, they're redirected back to the web app along with their credentials.
Mobile / Desktop app - Embed your consumer key/secret in the app, knowing it could be stolen and used to impersonate your app in our statistics. Oh well. App generates the OAuth authorize URL and displays it to user saying "copy this to your browser" or, if the platform allows, open the default browser and point it to the authorize URL. User logs in, authorizes the app, and is shown their authorization verifier (we'll need a better name). Copy and paste that into the app and it has everything it needs to get an access token.
Summary: For web apps, user does nothing except login and click authorize. For desktop/mobile, they have the extra steps of going to the browser, then copying and pasting the verifier that's displayed. Not great, but it seems to work for Twitter.
I have read some interesting ideas about desktop apps asking for username/password then exchanging that for an access token. They still use OAuth for all API calls, but bypass the entire authorize workflow and instead just ask the user for username/password. It's definitely a better user experience, but I really dislike training users to give out username/password. I think it's a bad habit all around, and users should be suspicious when any app asks for that.
Web apps - Normal OAuth flow. Redirect users to our OAuth authorize page, when they accept, they're redirected back to the web app along with their credentials.
Mobile / Desktop app - Embed your consumer key/secret in the app, knowing it could be stolen and used to impersonate your app in our statistics. Oh well. App generates the OAuth authorize URL and displays it to user saying "copy this to your browser" or, if the platform allows, open the default browser and point it to the authorize URL. User logs in, authorizes the app, and is shown their authorization verifier (we'll need a better name). Copy and paste that into the app and it has everything it needs to get an access token.
Summary: For web apps, user does nothing except login and click authorize. For desktop/mobile, they have the extra steps of going to the browser, then copying and pasting the verifier that's displayed. Not great, but it seems to work for Twitter.
I have read some interesting ideas about desktop apps asking for username/password then exchanging that for an access token. They still use OAuth for all API calls, but bypass the entire authorize workflow and instead just ask the user for username/password. It's definitely a better user experience, but I really dislike training users to give out username/password. I think it's a bad habit all around, and users should be suspicious when any app asks for that.
In order to really protect users, you'd need something like the banks where they give you an authentication image that you choose when you create your account, that's only stored on OP's servers, so you know it's really OP that you're logging into... otherwise the hosted browser could just send you to a fake site to steal your password. This still requires the desktop app to host a browser that sends you to the website, and retrieves the access token... but that seems like something that could be written once and reused. (this assumes an embedded browser in the desktop app, so you can't trust the URL/web page it shows you is really yours, without secret info from the site).
Without that, you'd need to have the users do what Chainsaw is talking about, and log into the site using a normal browser (in which we trust the URL will tell us when we're really connected to OP), and then get an access token from there to give to the desktop app.
The first one is more work, and the second one is just not a viable user experience, I think.
It's an interesting problem, for sure.
I'm adding the dynamic sheet data to the Characters API methods. That means it will be possible to build things like an importer for .dnd4e files or PCGen exports.
The dynamic sheet data is a little trickier to work with, and you risk wiping out someone's character in a heartbeat, so be careful!