Downloadable campaign backups

This is the feature I’m waiting for. The local backup doesn’t need to be in a fancy format, I’d be happy with knowing can’t loose my content. Maintaing wiki links would be nice, but the content itself is of primary concern.

This is the feature I’m waiting for. The local backup doesn’t need to be in a fancy format, I’d be happy with knowing can’t loose my content. Maintaing wiki links would be nice, but the content itself is of primary concern.

I definitely would like the idea of a campaign backup, and I have no need for importing. I’m not the most web savvy guy, but I would put in a vote for xml.

I definitely would like the idea of a campaign backup, and I have no need for importing. I’m not the most web savvy guy, but I would put in a vote for xml.

ABSOLUTELY a fantastic idea. I would LOVE to have local XML data in case of issues, or to check on old stuff from time to time. I am not familiar with Atom, but I’ll check it out.

ABSOLUTELY a fantastic idea. I would LOVE to have local XML data in case of issues, or to check on old stuff from time to time. I am not familiar with Atom, but I’ll check it out.

This sounds like a great idea! Especially if you are going to be somewhere without Internet access for an extended time, and would like the information as a reference. I think the .zip of the files would be great to keep the organization and formatting that makes OP great. That way if you do end up editing text from the local version, you could see it next to the rest of your campaign data.

But any format that wouldn’t be too difficult to sort through the text would be fine.

Long run, if it’s easy enough to export data and formatting, it might make it easier to port it to other applications(like a moble version for a popular smart device, if that’s ever a plan for you fine folks)

This sounds like a great idea! Especially if you are going to be somewhere without Internet access for an extended time, and would like the information as a reference. I think the .zip of the files would be great to keep the organization and formatting that makes OP great. That way if you do end up editing text from the local version, you could see it next to the rest of your campaign data.

But any format that wouldn’t be too difficult to sort through the text would be fine.

Long run, if it’s easy enough to export data and formatting, it might make it easier to port it to other applications(like a moble version for a popular smart device, if that’s ever a plan for you fine folks)

Sounds like a super idea, and also a super premium idea. I’d gladly pay even more for an ascendant+plus membership if it ensured this feature made it into the “we’ll do it!” pile.

Sounds like a super idea, and also a super premium idea. I’d gladly pay even more for an ascendant+plus membership if it ensured this feature made it into the “we’ll do it!” pile.

Why not write all the pages out as PDFs? That would allow you to preserve uploaded images, too. One document per wiki/log page, then zip all the documents into one file for download or e-mail.

Why not write all the pages out as PDFs? That would allow you to preserve uploaded images, too. One document per wiki/log page, then zip all the documents into one file for download or e-mail.

Is there an “issue tracker” somewhere that lists what you guys are currently working on?

Offline backups are a fantastic idea! There are, of course, tradeoffs between flexibility and usability. A ZIP of HTML (and image?) files is more useful to most people, but Atom, XML, or SQL would give computer savvy users a lot more options.

It’s a lot to ask, but I think you should embrace emerging web standards from HTML5 (cache manifest, local SQL) to allow someone to export their entire campaign basically as a client-side OP site. This would lead into allowing import/export in the future, or better yet, “offline mode” and “synching to the OP cloud.”

A world with a fully-featured OP mobile app would be a better world. The local data for such an app would be a backup of your campaign. This is huge in scope, though, so I’m not sure how feasible it really is.

Is there an “issue tracker” somewhere that lists what you guys are currently working on?

Offline backups are a fantastic idea! There are, of course, tradeoffs between flexibility and usability. A ZIP of HTML (and image?) files is more useful to most people, but Atom, XML, or SQL would give computer savvy users a lot more options.

It’s a lot to ask, but I think you should embrace emerging web standards from HTML5 (cache manifest, local SQL) to allow someone to export their entire campaign basically as a client-side OP site. This would lead into allowing import/export in the future, or better yet, “offline mode” and “synching to the OP cloud.”

A world with a fully-featured OP mobile app would be a better world. The local data for such an app would be a backup of your campaign. This is huge in scope, though, so I’m not sure how feasible it really is.

Thanks for the feedback, folks.

@SpikeBlade – We discussed it and decided to make it a free feature. We believe it’s important to support portability.

@ZorkFox – PDF is an interesting idea, but I think we’d go the HTML/zip route instead. PDF is too closed off, meaning it would be much more difficult to get at the underlying text.

@Mark – We’re definitely looking at HTML5. I don’t know a lot about the offline storage stuff, as I’ve been looking more at some of the markup/javascript features. Huge in scope is an understatement, though. We’re trying to placate the calls for backups without biting off more than we can chew. Also, to your other question, we do have an issue tracker, but we keep it private. Our goal is to under-promise and over-deliver, so we try to keep our work private until we’re ready to release it. We’ve been burned too many times where we had to abandon something because it got out of hand, and it would be much harder to do that if we had publicly committed to it.

As to a mobile app…maybe some day. It will probably have to wait until I have a mobile device to play with, and seeing as how I’m kind of pinching pennies these days, that may be a ways off.

Thanks for the feedback, folks.

@SpikeBlade – We discussed it and decided to make it a free feature. We believe it’s important to support portability.

@ZorkFox – PDF is an interesting idea, but I think we’d go the HTML/zip route instead. PDF is too closed off, meaning it would be much more difficult to get at the underlying text.

@Mark – We’re definitely looking at HTML5. I don’t know a lot about the offline storage stuff, as I’ve been looking more at some of the markup/javascript features. Huge in scope is an understatement, though. We’re trying to placate the calls for backups without biting off more than we can chew. Also, to your other question, we do have an issue tracker, but we keep it private. Our goal is to under-promise and over-deliver, so we try to keep our work private until we’re ready to release it. We’ve been burned too many times where we had to abandon something because it got out of hand, and it would be much harder to do that if we had publicly committed to it.

As to a mobile app…maybe some day. It will probably have to wait until I have a mobile device to play with, and seeing as how I’m kind of pinching pennies these days, that may be a ways off.

I know there isn’t much of an “industry” in online campaign management tools, but it might not be a bad idea to open a dialog with other providers (such as Epic Words) and potential consumers (like me!) to create a standard format.

I agree that CSV and HTML are terrible ideas. Atom is less bad, but still not ideal. A custom XML schema is the closest to an ideal. Publishing the schema would enable consumers and other providers to validate the XML they have in-hand.

A final option may be JSON. It’s just as customizable as XML and much less verbose, which is of course great. The trade-off is that there’s no standard validation or schema mechanism.

I know there isn’t much of an “industry” in online campaign management tools, but it might not be a bad idea to open a dialog with other providers (such as Epic Words) and potential consumers (like me!) to create a standard format.

I agree that CSV and HTML are terrible ideas. Atom is less bad, but still not ideal. A custom XML schema is the closest to an ideal. Publishing the schema would enable consumers and other providers to validate the XML they have in-hand.

A final option may be JSON. It’s just as customizable as XML and much less verbose, which is of course great. The trade-off is that there’s no standard validation or schema mechanism.

@Mark The problem with an HTML5 local DB, as I understand it, is that it’s difficult for users to get their data out without using the original website anyway. I think that makes it a poor choice, but again that’s all based on my current understanding which could be wrong.

@Mark The problem with an HTML5 local DB, as I understand it, is that it’s difficult for users to get their data out without using the original website anyway. I think that makes it a poor choice, but again that’s all based on my current understanding which could be wrong.

Having a backup option would be great, and I think most of us would feel better if we knew that there is an option to save all the work we put in our campaigns. That fact alone could even convince people to join Obsidian Portal and dedicate their efforts in this website, instead of a different one.

I’m not familiar with most of the options you mentioned, so I won’t lie and vote for one or the other. However, I think that as long as text is saved, then the heart of the campaign would be safe. It would also be interesting if the textile code could be saved as well, but maybe that’s already implied in the options you listed (again, I’m not familiar with each of them).

Having a backup option would be great, and I think most of us would feel better if we knew that there is an option to save all the work we put in our campaigns. That fact alone could even convince people to join Obsidian Portal and dedicate their efforts in this website, instead of a different one.

I’m not familiar with most of the options you mentioned, so I won’t lie and vote for one or the other. However, I think that as long as text is saved, then the heart of the campaign would be safe. It would also be interesting if the textile code could be saved as well, but maybe that’s already implied in the options you listed (again, I’m not familiar with each of them).

YES!

YES!

@Bill – I considered JSON as well, but it’s more of a machine-machine serialization layer. I love JSON probably more than Atom these days, but I don’t think it’s a good fit here. If we were passing data directly to a consuming service, then JSON makes sense.

As to creating a standard…I dunno. I’d guess that our schema and Epic Words is different enough that working out some common export format would be pretty tough. I will, however, double-check to see if they have this feature. If so, and their format makes sense, I’ll see about following as closely as possible. If they don’t have it, then they’re welcome to follow our format First-mover advantage and all that.

@Bill – I considered JSON as well, but it’s more of a machine-machine serialization layer. I love JSON probably more than Atom these days, but I don’t think it’s a good fit here. If we were passing data directly to a consuming service, then JSON makes sense.

As to creating a standard…I dunno. I’d guess that our schema and Epic Words is different enough that working out some common export format would be pretty tough. I will, however, double-check to see if they have this feature. If so, and their format makes sense, I’ll see about following as closely as possible. If they don’t have it, then they’re welcome to follow our format First-mover advantage and all that.

Right now I’m leaning toward the custom XML schema. It would allow for maximum semantic preservation. Plus, if there’s someone in the community who wanted to write a parser or an XSLT, it could be converted to HTML with little difficulty.

Right now I’m leaning toward the custom XML schema. It would allow for maximum semantic preservation. Plus, if there’s someone in the community who wanted to write a parser or an XSLT, it could be converted to HTML with little difficulty.

@Bill: Yeah, browser vendors don’t seem to want to build a SQL Manager into their browsers. Cookie managers are already hard enough for most people. However, the difficulty of accessing that local data was part of the reason I mentioned having a fully client-side version of OP that comes with the backup. It would allow you to access the exported data indirectly, just as if you were connected to OP. The whole package (site + data) would be like a proprietary format, only built off of web standards.

@Micah, thanks for the responses. I tend to be overly ambitious with my personal projects and very conservative with my work projects, so I understand keeping your issue tracker private.

How are things stored in the backend? Blog posts, images, wiki pages, maps, comments… are they all in the same place? Depending on the structure, there may already be a very natural way to package it all up. Hopefully I’m not asking you to reveal trade secrets or anything.

@Bill: Yeah, browser vendors don’t seem to want to build a SQL Manager into their browsers. Cookie managers are already hard enough for most people. However, the difficulty of accessing that local data was part of the reason I mentioned having a fully client-side version of OP that comes with the backup. It would allow you to access the exported data indirectly, just as if you were connected to OP. The whole package (site + data) would be like a proprietary format, only built off of web standards.

@Micah, thanks for the responses. I tend to be overly ambitious with my personal projects and very conservative with my work projects, so I understand keeping your issue tracker private.

How are things stored in the backend? Blog posts, images, wiki pages, maps, comments… are they all in the same place? Depending on the structure, there may already be a very natural way to package it all up. Hopefully I’m not asking you to reveal trade secrets or anything.

@Mark – All the text data is in the RDBMS. No secrets there. Although in the future we may add a Mongo instance for some ideas we’re kicking around. A SQL dump is not completely out of the question, but that’s a little more open than I’d like to be, plus it’d be worthless for anyone who doesn’t have RDBMS experience. I’d choose XML long before a raw SQL dump.

@Mark – All the text data is in the RDBMS. No secrets there. Although in the future we may add a Mongo instance for some ideas we’re kicking around. A SQL dump is not completely out of the question, but that’s a little more open than I’d like to be, plus it’d be worthless for anyone who doesn’t have RDBMS experience. I’d choose XML long before a raw SQL dump.

@Micah – If it’s already stored in an RDBMS, then the local SQL route may actually be more feasible than I thought. But that is a topic for the future, when browser support for that feature is widespread.

I agree that XML is the best choice for now. It’s ubiquitous, it’s “human-readable,” and a SQL schema maps onto an XML schema pretty easily. Maybe you could include some XSLT to transform the things into a truly human-readable format (like HTML). That way, it’s useful to users across a broad spectrum of computing experience.

Would only the GM be able to export a campaign? That would help keep all the “GM Only” text secret.

@Micah – If it’s already stored in an RDBMS, then the local SQL route may actually be more feasible than I thought. But that is a topic for the future, when browser support for that feature is widespread.

I agree that XML is the best choice for now. It’s ubiquitous, it’s “human-readable,” and a SQL schema maps onto an XML schema pretty easily. Maybe you could include some XSLT to transform the things into a truly human-readable format (like HTML). That way, it’s useful to users across a broad spectrum of computing experience.

Would only the GM be able to export a campaign? That would help keep all the “GM Only” text secret.

Yes, only the GM will be able to export, and we may put a limit, like once a week. This will be very stressful on the database. When you browse the site, it’s like looking at a page of a book. The database serves up each page, one at a time. Downloading a backup is like requesting the entire book. If lots of people are doing this all the time, it will definitely slow things down.

I don’t think we’ll supply an XSLT, but that’s something someone in the community could definitely put together. We have kind of a standing offer of a free t-shirt, some free Ascendant time, and our eternal gratitude for anyone who does stuff like that.

Are there any tools for easily running an XSLT against an XML file? I’ve used some of the linux command line stuff, but it was always a real pain. Is there a way to specify the XSLT in the XML file so that browsers can do the formatting?

Yes, only the GM will be able to export, and we may put a limit, like once a week. This will be very stressful on the database. When you browse the site, it’s like looking at a page of a book. The database serves up each page, one at a time. Downloading a backup is like requesting the entire book. If lots of people are doing this all the time, it will definitely slow things down.

I don’t think we’ll supply an XSLT, but that’s something someone in the community could definitely put together. We have kind of a standing offer of a free t-shirt, some free Ascendant time, and our eternal gratitude for anyone who does stuff like that.

Are there any tools for easily running an XSLT against an XML file? I’ve used some of the linux command line stuff, but it was always a real pain. Is there a way to specify the XSLT in the XML file so that browsers can do the formatting?

I think I’d like a .pdf the best, as it works cross-platform nicely, can use pictures, and you could put Adventure Logs and Wiki pages in 2 separate files. I’m sure whatever happens in the end will work though.

I think I’d like a .pdf the best, as it works cross-platform nicely, can use pictures, and you could put Adventure Logs and Wiki pages in 2 separate files. I’m sure whatever happens in the end will work though.

I think a back up is a great idea. I understand the need for making it portable to other sites. My concern is I have not found another site like OP. So I really don’t want to go any place else. What I want in a back up is something that I can use on my PC that I can still use in my game. So for me this would be my order of Preference.

1. PDF
2. Word Doc
3. HTML
4. XML
5. Some other format

To help with not making it better.
1. Could you allow a back up in multiple formats. For example have something like a PDF and a advance option. So those that just want there work can have it and those that are more portablity minded can have there. Mostly these two groups will not cross.
2. Instead of Time frame for backing up can you do a percentage of content. Like say when the user has changed 5% or more of the content since last back up they can back up again.

I think a back up is a great idea. I understand the need for making it portable to other sites. My concern is I have not found another site like OP. So I really don’t want to go any place else. What I want in a back up is something that I can use on my PC that I can still use in my game. So for me this would be my order of Preference.

1. PDF
2. Word Doc
3. HTML
4. XML
5. Some other format

To help with not making it better.
1. Could you allow a back up in multiple formats. For example have something like a PDF and a advance option. So those that just want there work can have it and those that are more portablity minded can have there. Mostly these two groups will not cross.
2. Instead of Time frame for backing up can you do a percentage of content. Like say when the user has changed 5% or more of the content since last back up they can back up again.

I worked on it this weekend, and I finished a first version (call it version 0.1). It exports in XML using a custom schema that looks a little like Atom.

My hope is that someone in the community can step up and create an XML -> PDF or XML -> HTML converter that will convert the raw XML into something more useful. Our core goal here was not to recreate the website in a downloadable format, so we’re going to skip that.

@Matthew – Let me answer your questions directly:

1) No. We try to avoid options as much as possible. For any given feature, if there are N optional ways to do it, then it means we have to write at least N times as much code to accomplish it. This means we have less time to devote to other features. However, if we export in a portable format like XML, then other people can write translators for that format to create the “prettier” versions like HTML and PDF.

2) It’s not trivial to compute how much content has changed. The time restriction is much easier, and should suffice in 99% of cases. In fact, to start with, there will be no restriction. However, if we see that the server is slowing down due to people making too many backups, then we’ll have to figure something out.

I worked on it this weekend, and I finished a first version (call it version 0.1). It exports in XML using a custom schema that looks a little like Atom.

My hope is that someone in the community can step up and create an XML -> PDF or XML -> HTML converter that will convert the raw XML into something more useful. Our core goal here was not to recreate the website in a downloadable format, so we’re going to skip that.

@Matthew – Let me answer your questions directly:

1) No. We try to avoid options as much as possible. For any given feature, if there are N optional ways to do it, then it means we have to write at least N times as much code to accomplish it. This means we have less time to devote to other features. However, if we export in a portable format like XML, then other people can write translators for that format to create the “prettier” versions like HTML and PDF.

2) It’s not trivial to compute how much content has changed. The time restriction is much easier, and should suffice in 99% of cases. In fact, to start with, there will be no restriction. However, if we see that the server is slowing down due to people making too many backups, then we’ll have to figure something out.