Difference between revisions of "IPKG Service"

From WebOS Internals
Jump to navigation Jump to search
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Functional specificatino for a binary service to talk to a mojo over-the-air installer working from ipkg feeds.  
+
= THE INFORMATION ON THIS PAGE IS OBSOLETE. DO NOT USE IT. =
  
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.
+
Functional specifications for a binary service to talk to a mojo over-the-air installer working from ipkg feeds.  
  
The mojo app talks to the service purely by coded requests. The service returns JSON objects. 
+
Note:  This portion refers only to the conversation between the mojo app and the service, which then talks to ipkg on the Pre.
  
==REQUEST 1  (literally, send the service a 1)  ==
+
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?   
 
Meaning:  Hi I'm back, did you miss me?   
Line 13: Line 16:
 
The service internally does the following:   
 
The service internally does the following:   
  
# 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.   
+
# 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
 
#::    ipkg -o /var update
 
# 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
# request 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)
  
The service RETURNS EITHER "Ready" or "Ready no Update"  (I can't imagine a "not ready."  It would require IPKG to not respond....)
+
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.)  ==
+
==Request 2  "Give me a list of the things you have installed."  (literally send 2.)  ==
 
Returns a JSON object with the information from   
 
Returns a JSON object with the information from   
 
     ipkg -o /var info <package> for each package.   
 
     ipkg -o /var info <package> for each package.   
Line 46: Line 49:
 
one for each package that exists in the list of installed apps.   
 
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.  ==
+
==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...  
 
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...  
Line 76: Line 79:
 
==Request 6 "Delete the package with ID number XYZ"  ==
 
==Request 6 "Delete the package with ID number XYZ"  ==
  
Service checks for /var/usr/lib/ipkg/<package>.prem 
+
Service checks for /var/usr/lib/ipkg/info/<package>.prerm
  
 
and asks the user for consent to run it, just like for postinst.
 
and asks the user for consent to run it, just like for postinst.
Line 96: Line 99:
  
 
thanks.
 
thanks.
 +
==

Latest revision as of 01:18, 17 December 2010

THE INFORMATION ON THIS PAGE IS OBSOLETE. DO NOT USE IT.

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.

==