Difference between revisions of "IPKG Service"

From WebOS Internals
Jump to navigation Jump to search
Line 17: Line 17:
 
# Request from ipkg a complete list of everything that is installed.   
 
# Request from ipkg a complete list of everything that is installed.   
 
#::    ipkg -o /var list_installed
 
#::    ipkg -o /var list_installed
# Tequest from ipkg a complete list of everything that is AVAILABLE  
+
# Request from ipkg a complete list of everything that is AVAILABLE  
 
#::    ipkg -o /var list
 
#::    ipkg -o /var list
 
# The service (without being asked)  compares those two lists, and prepares a list of packages that are upgrade/updateable.  (where the version in c) is higher than the version  in b)
 
# The service (without being asked)  compares those two lists, and prepares a list of packages that are upgrade/updateable.  (where the version in c) is higher than the version  in b)

Revision as of 05:39, 6 August 2009

Functional specifications for a binary service to talk to a mojo over-the-air installer working from ipkg feeds.

Note: This portion refers only to the conversation between the mojo app and the service, which then talks to ipkg on the Pre.

It does not account for any EXTRA conversations that the installer might have with another web server to get icons, screenshots, etc.

The mojo app talks to the service purely by coded requests. The service returns JSON objects.

Request 1 (literally, send the service a 1)

Meaning: Hi I'm back, did you miss me?

The service internally does the following:

  1. If it's been more than 24 hours since the last time an update was run from the repository, go do one. If this is the first run, go do one. If no connectivity is available just now, note that and go on. Don't crash.
    ipkg -o /var update
  2. Request from ipkg a complete list of everything that is installed.
    ipkg -o /var list_installed
  3. Request from ipkg a complete list of everything that is AVAILABLE
    ipkg -o /var list
  4. The service (without being asked) compares those two lists, and prepares a list of packages that are upgrade/updateable. (where the version in c) is higher than the version in b)

The service RETURNS EITHER "Ready" or "Ready no Update" (I can't imagine a "not ready." It would require IPKG to not respond....)

Request 2 "Give me a list of the things you have installed." (literally send 2.)

Returns a JSON object with the information from

    ipkg -o /var info <package> for each package.   

for each package that is installed this is AMAZINGLY EASY because we just basically wrap {} braces around what's returned from the package request for each installed package.

{ ID: 123, ipkginfo: { Package: org.jwz.daliclock, Version: 2.29.0, Status: unknown ok not-installed, Section: web, Architecture: all, Maintainer: Jamie Zawinski <jwz@jwz.org>, MD5Sum: 783a0df21ded02f9374b0f4c2cb82b02, Size: 38184, Filename: org.jwz.daliclock_2.29.0_all.ipk, Source: http://www.jwz.org/xdaliclock/daliclock-229.ipk, Description: Dali Clock } } one for each package that exists in the list of installed apps.

Request 3 Send me a list of the things that can be updated.

Service returns a JSON identical to the one in number 2, except it adds a field "NewVersion:" -- it provides this from the comparison it did back in step 1...

Request 4 Send me a list of EVERYTHING ON THE FEED.

See the response to 2, except for everything.

Request 5 "Install number XYZ"

Using the unique ID provided in the list above, Install that app.

The service does:

   ipkg -o /var install <package>

Then, the service checks to see if /var/usr/lib/ipkg/info/<package>.postinst exists.

The service returns a JSON in one of two states:

1) {status: Done} 2) {status: Postinst, script: {contents of postinst script}}

If the status is POSTINST the service is waiting for a "Proceed" or a "Cancel." it's the responsibility of the mojo app to send "proceed" or "cancel" to the service.

If the service gets proceed, it runs the postinst script. If it gets cancel, it does not and deletes the script. . If it gets SOMETHING ELSE FIRST (like a completely different request) -- same result as cancel.

Request 6 "Delete the package with ID number XYZ"

Service checks for /var/usr/lib/ipkg/info/<package>.prerm

and asks the user for consent to run it, just like for postinst.

Once that is done, the service runs:

   ipkg -o /var remove <package> 


Request 5 "Do an update from the repository now. " same as 1 but with an unconditional update. (assuming there's connectivity.)

Notes

This architecture allows you to list and delete apps WITHOUT CONNECTIVITY.

You can't INSTALL apps that way. Duh. sorry.

Note that there is NO URL INSTALL in this version.

thanks.