1 / 13

SRAMP-8 Update ZIP Publishing

SRAMP-8 Update ZIP Publishing. Issue 8 – ZIP Publishing. ZIP Publishing in the contributed documents needs to be reviewed and revisited. The basics of zip publishing that are currently defined are a start, but this feature needs to be tightened up. The text of this needs clarification. .

xuan
Download Presentation

SRAMP-8 Update ZIP Publishing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SRAMP-8 UpdateZIP Publishing

  2. Issue 8 – ZIP Publishing • ZIP Publishing in the contributed documents needs to be reviewed and revisited. The basics of zip publishing that are currently defined are a start, but this feature needs to be tightened up. The text of this needs clarification.

  3. Issues(from 1st f2f) • File specification • Tightly bound to ZIP • Structure of the package • Usecases to support • Upload new documents • Update documents • Get package with documents

  4. Decisions/Nots from 1st f2f • It is proposed that we create a new issue for the getPackage() functionality. The group decided that the new issue be captured and created and marked as an item for a future release of S-RAMP. • Decision to use a new mime type "x-sramp-archive“ • file extension will be sramp for the zip packages • Metadata • SRAMP-PACAKGE-VERSION - this is to be optional in the metadata for now. If there is another version of the package data then we would need to supllythis at another time. This can either be included and made optional initially. If it is omitted package level 1 is assumed. • Need to figure out what the *.atom files are in the package. Vince to try to dosome research and find that out. • Metadescriptionseems to be very close to what we need. Need to cross reference this proposal with the simple POST of a document and its header.

  5. Status • ZIP reference removed • application/x-sramp-archive used • .sramp file extension introduced • Get-package UC moved to next version of the specification • Metadata not mentioned in the document • Currently there is no usage of them either in the HTTP Batch POST and Package file POST operations

  6. Next Issues • Mapping of the created entries to files in the package • Failure handling • HTTP Batch allows partial creation, but Package publishing allows just all-or-nothing behavior • There is not clear way to get the failure description and failed file (like in HTTP Batch) • Performance • Due to all-or-nothing behavior the performance can be a problem. For example if package contains 1000s of files, then the transaction can be large (memory) and long-lived (based on the implementation it can lock resources), so it can block the server

  7. Issue: Mapping & Failure • Mapping resolved by reusing the same response as HTTP Batch Post uses • It returns response of type Content-Type: multipart/http;version=1.1;msgtype=response;boundary=batch • Failure handling • The same approach as HTTP Batch POST is using

  8. Package POST Response - Success • Response is HTTP 200, multipart/http • Used the same response as for HTTP Batch • Part’s Content-id is • <full path of processed file>@package • Full path is w/o leading / • E.g. a.wsdl@package, a/b/c.xsd@package • Response does not contain atom:entry of indirectly created artifacts (i.e., derived, …)

  9. Example: Success Package POST REQUEST POST /s-ramp HTTP/1.1 Host: example.org Content-Type: application/x-sramp-archive Content-Length: nnn { ...binary S-RAMP package data...} RESPONSE HTTP/1.1 200 OK Date: Tues, 26 May 2009 13:13:55 GMT+02:00 Content-Length: nn Content-Type: multipart/http;version=1.1;msgtype=response;boundary=package Mime-Version: 1.0 --package Content-ID: <b.xsd@packaga> HTTP/1.1 201 Created Date: Tues, 26 May 2009 13:13:55 GMT+02:00 {Created/updated Atom:entryfor file /b.xsd omitted for clarity} --package Content-ID: <a.wsdl@package> HTTP/1.1 201 Created Date: Tues, 26 May 2009 13:13:55 GMT+02:00 {Created/updated Atom:entryfor file /a.wsdl omitted for clarity}

  10. Package POST Response - Failure • Response is HTTP 200, multipart/http • Used the same response as for HTTP Batch • Part’s Content-id is • <full path of processed file>@package • Full path is w/o leading / • E.g. a.wsdl@package, a/b/c.xsd@package • Package behavior is complete rollback, so only the first failed file is reported

  11. Example: Failed Package POST REQUEST POST /s-ramp HTTP/1.1 Host: example.org Content-Type: application/x-sramp-archive Content-Length: nnn Accept: multipart/related { ...binary S-RAMP package data...} RESPONSE HTTP/1.1 409 Conflict Date: Tues, 26 May 2009 13:13:55 GMT+02:00 Content-Length: nn Content-Type: multipart/http;version=1.1;msgtype=response;boundary=package Mime-Version: 1.0 --package Content-ID: <a.wsdl@package> HTTP/1.1 409 Conflict Date: Tues, 26 May 2009 13:13:55 GMT+02:00 {Explanation of error condition}

  12. Issue: Performance • Not resolved yet • Must be discussed • Issues • Current behavior specification is the ‘single transaction’ • If implemented as DB transaction, the it can easily exhaust the server/DB resource on large data • Create/update of the artifacts • To Lock or To not-lock the artifacts? i.e., transaction issolation • Large package file • Long processing time, connection can timeout, so the client fails

  13. Another Issues • multipart/http • Not officially registered MIME type • Can we use it in HTTP Batch POST/Package POST? • Package POST partial failure • HTTP Batch POST allows partial failure • Can we allow it also for Package POST?

More Related