html5的service worker,GitHub - w3c/ServiceWorker: Service Workers

What’s going on here?

Service workers are a new browser feature that provide event-driven scripts that run independently of web pages. Unlike other workers, service workers can be shut down at the end of events, note the lack of retained references from documents, and they have access to domain-wide events such as network fetches.

Service workers also have scriptable caches. Along with the ability to respond to network requests from certain web pages via script, this provides a way for applications to “go offline”.

Service workers are meant to replace the (oft maligned) HTML5 Application Cache. Unlike AppCache, service workers are comprised of scriptable primitives with an extensive use of Promises that make it possible for application developers to build URL-friendly, always-available applications in a sane and layered way.

To understand the design and how you might build apps with service workers, see the explainer document.

Spec and API development

For the nitty-gritty of the API, the draft W3C specifications are authoritative. Service Workers Nightly is a living document. Service Workers 1 is a subset of the nightly version that is advancing toward a W3C Recommendation. For implementers and developers who seek all the latest features, Service Workers Nightly is a right document that is constantly reflecting new requirements. For version 1, contributors plan to focus on fixing bugs and resolving compatibility issues without including new features from the nightly version.

Spec development happens via issues in this repository. For general discussion, please use the public-webapps@w3.org mailing list with a Subject: prefix of [service-workers].

Updates to the spec must reference resolved issues marked needs spec.

To make edits to the design, please send pull requests against the Nightly spec on the master branch. We use bikeshed. So, change docs/index.bs and submit it with the corresponding bikesheded index.html.

Examples

The W3C Web Mobile Group have defined a series of use-cases where service worker is particularly useful. You can help by adding more use cases, draft implementation code, or even working examples once browsers support the required APIs.

About labels and milestones on issues

This is to explain how we use labels and milestones to triage the issues. Note: This is a draft, suggestions for improvements are welcomed.

Prioritization

enhancement: is for anything that was assessed as not having any impact on the decisions for the current milestone and can therefore be safely discussed, rejected or prioritized later.

milestone: is used to mark issues we agreed to get done in principle by a given revision. For the sake of efficiency, we tend to only focus on the current milestone and leave everything else without specific milestones.

impacts MVP: is used to mark issues impacting the “Minimal Viable Product”. The MVP is the minimal scope of API that can solve actual use cases. These issues have the highest priority.

Risk labels for impacts MVP issues

medium risk: to further refine the “impacts MVP” issues. It indicates that the issue is moderately complex and that reaching a conclusion might take some time. These are of higher priority than issues with no risk label but are of lower priority than issues with a “high risk” label.

high risk: to further refine the “impacts MVP” issues. It indicates that the issue is significantly complex and that reaching a conclusion might take a lot of time and effort. These are of higher priority than issues with no risk label or a “medium risk” label.

Actions

needs spec: a decision has been made and the spec needs to be updated.

spec detail: has no significant implications for implementers nor web developers.

decided: to record that a decision has been made.

invalid: when something doesn’t constitute a valid issue.

wontfix: a decision has been made not to pursue this issue further.

duplicate: when a similar issue has already been filed.

bug: an oversight that needs to be fixed.

Areas

fetch: relates to Fetch

lifecycle: relates to lifecycle aspects of service worker

cache: relevant to the Cache APIs

question: not an actual issue. Items that have been filed in order to gain a better understanding of service worker.

我想将frontend 也是用volumes,将其映射到/app/frontend目录,在/app/frontend下install以及build,如何实现 docker-compose.yml文件: version: '3' services: frontend: build: context: ./frontend dockerfile: Dockerfile ports: - 8010:80 restart: always backend: build: context: ./backend dockerfile: Dockerfile volumes: - /app/backend:/app environment: - CELERY_BROKER_URL=redis://redis:6379/0 command: python manage.py runserver 0.0.0.0:8000 ports: - 8011:8000 restart: always celery-worker: build: context: ./backend dockerfile: Dockerfile volumes: - /app/backend:/app environment: - CELERY_BROKER_URL=redis://redis:6379/0 command: celery -A server worker -l info --pool=solo --concurrency=1 depends_on: - redis - backend restart: always celery-beat: build: context: ./backend dockerfile: Dockerfile volumes: - /app/backend:/app environment: - CELERY_BROKER_URL=redis://redis:6379/0 command: celery -A server beat -l info --scheduler django_celery_beat.schedulers:DatabaseScheduler depends_on: - redis - backend restart: always redis: image: redis:latest ports: - 6379:6379 restart: always mysql: image: mysql:latest environment: - MYSQL_ROOT_PASSWORD=sacfxSql258147@ ports: - 8016:3306 volumes: - ./mysql:/var/lib/mysql restart: always frontend:dockerfile文件 FROM node:16.18.1 WORKDIR /app/frontend COPY package*.json ./ RUN npm install COPY . . RUN npm run build:prod FROM nginx:latest COPY --from=0 /app/frontend/dist/ /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]
最新发布
07-14
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值