Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an archival use case. #137

Merged
merged 1 commit into from
Mar 5, 2018
Merged

Conversation

jyasskin
Copy link
Member

@jyasskin jyasskin commented Mar 5, 2018

Preview, Diff

@ibnesayeed @craigfrancis @TzviyaSiegman, you've been interested in this topic in issues like #105. What should I write in this section? I don't know enough about the topic to even describe the use case well.

I'm probably going to merge this without review to get it in time for the IETF deadline, but I'll definitely fix any comments that show up after that.

@jyasskin jyasskin merged commit 4876351 into WICG:master Mar 5, 2018
@jyasskin jyasskin deleted the archival-use-case branch March 5, 2018 23:28
@craigfrancis
Copy link

Thanks for adding these notes @jyasskin

I'm not sure how much I can add at the moment, as you have noted that packages could be used for archival purposes (actual implementation will probably be for the browsers to decide), and the only other point I have is the suggestion/concerns about JavaScript basing the date/time off the timestamp of the package (which is already covered).

@ibnesayeed
Copy link
Contributor

Thanks @jyasskin for this. The language used seems a little too informal. That said, I think we need to invite more people from the web arching community to give their input on the archival aspect here or in #105. In case of WARC file-based replay, certificates of the archive host are used in TLS communication rather than the original ones. I am CCing @anjackson, @hvdsomp, @phonedude, @ikreymer, @galsondor, and @machawk1 here for any comments on it.

@jmulliken
Copy link

I have some limited experience creating WARCs. Without knowing too much about the back-end, I can add that this approach would work for many html/css/javascript publications. We are currently using it for amenable web-based publications at Stanford University Press. Here, for example, is a web archive of our latest web publication: https://webrecorder.io/sup/enchanting-the-desert I think you could generalize a use case from this, but the type of publication is not the typical kind this group has looked at so far. That said I would LOVE for it to become part of the conversation.

@BigBlueHat
Copy link

From a Web Publication WG perspective, we'll want Packaged Web Publications (PWP) to live well beyond the rental of a domain name or certificate. Reducing the contents to a sandbox-ed experience may be fine if the contents are primarily (or exclusively) descriptive (i.e. little to no JS involved).

Ideally, one could still experience a PWP they'd downloaded (or purchased) even if the domain or cert expired just days prior. Essentially, we don't want a reader's experience of a publication dependent on a rent-based architecture.

And huge 👍 to involving a wider audience (i.e. WARC and friends) in the development of this potentially very valuable addition to the Web platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants