RFC: activity bundles

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Dan Williams-4
http://wiki.laptop.org/go/Activity_Bundles

Comments welcome.  Especially from you, Blizzard, since easily
installable and transferable activities is your baby :)

Dan


Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Bert Freudenberg

Am 01.09.2006 um 02:36 schrieb Dan Williams:

> http://wiki.laptop.org/go/Activity_Bundles
>
> Comments welcome.  Especially from you, Blizzard, since easily
> installable and transferable activities is your baby :)

You wrote: 'Each activity bundle must, in its root directory, contain  
a file with the same name as the activity bundle, but ending in  
".info" rather than ".activity"'.

IMHO a fixed name, like "activity.info" would be preferable.

We could then rename the bundle, try different versions etc. without  
needing to touch the inside. Also it would be simpler to script:

        grep default_type *.activity/activity.info

It's common practice as well, like JAR's manifest.mf or OS/X bundle's  
info.plist.

- Bert -

Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti
Bert Freudenberg wrote:

>
> Am 01.09.2006 um 02:36 schrieb Dan Williams:
>
>> http://wiki.laptop.org/go/Activity_Bundles
>>
>> Comments welcome.  Especially from you, Blizzard, since easily
>> installable and transferable activities is your baby :)
>
> You wrote: 'Each activity bundle must, in its root directory, contain
> a file with the same name as the activity bundle, but ending in
> ".info" rather than ".activity"'.
>
> IMHO a fixed name, like "activity.info" would be preferable.
>
> We could then rename the bundle, try different versions etc. without
> needing to touch the inside. Also it would be simpler to script:
>
>     grep default_type *.activity/activity.info
>
> It's common practice as well, like JAR's manifest.mf or OS/X bundle's
> info.plist.

Dan,

I tend to agree with Bert reasoning here.

More comments:

 >These should always be stored in an activity-specific directory in the
user's sugar profile, available >through the SUGAR_PROFILE environment
variable

Currently SUGAR_PROFILE is the profile name and the actual profile path
is ~/.sugar/$SUGAR_PROFILE. We might specify this or have the session to
export SUGAR_PROFILE_PATH based  on SUGAR_PROFILE.

>icon = activity-web
>This key is optional. It points to the activity's icon. The
>icon is first searched for in the >activity bundle's root directory, and
>if not found, is looked up in the current GTK icon >theme. It cannot
>contain a path.

What is the actual icon filename when looking up the bundle directory?
$icon + '.svg' or should the field be icon = activity-web.svg in that case?

We also need to specify the icon format (maybe thinking a bit more to
the css properties and possibly improving them). Something I was
thinking is that the css should be external, only the class attributes
should be required in the svg files... librsvg does not support external
css yet but we can just add the whole css to the svg file after loading.

>default_type = _web_olpc._udp
>Each activity must have a default type. This must follow the
>mDNS specification for serivce types and must be globally unique. This
>key is required. It is used as the service type for the mDNS service
>when the activity is shared.

Do we actually want to make this required? There are activities that
might not be sharable (terminal for example) or that haven't implement
sharing yet.

 >show_launcher = yes
 >This key is optional. If specified, it indicates that the activity
should show in the Sugar <http://wiki.laptop.org/go/Sugar> panel
 >launcher, represented by the activity's icon. If specified, the 'icon'
key must also be specified.

Since it's optional might be worth adding that it defaults to no.

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti

>
> >show_launcher = yes
> >This key is optional. If specified, it indicates that the activity
> should show in the Sugar <http://wiki.laptop.org/go/Sugar> panel
> >launcher, represented by the activity's icon. If specified, the
> 'icon' key must also be specified.
>

On a second thought... Since no is a special case we should probably
make yes the default and document it that way.

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Ivan Krstić-2
In reply to this post by Dan Williams-4
Dan Williams wrote:
> http://wiki.laptop.org/go/Activity_Bundles
>
> Comments welcome.

I'm quite troubled by the conspicuous lack of a 'Security' section in
any document that talks about code being automatically transferred over
the network.

Can you please add the section? I'd like to see a brief threat model and
how you're addressing it.

--
Ivan Krsti? <[hidden email]> | GPG: 0x147C722D
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti
In reply to this post by Marco Pesenti Gritti
Marco Pesenti Gritti wrote:
> Bert Freudenberg wrote:
>>
>> Am 01.09.2006 um 02:36 schrieb Dan Williams:
>>
>>> http://wiki.laptop.org/go/Activity_Bundles
>>>
>>> Comments welcome.  Especially from you, Blizzard, since easily
>>> installable and transferable activities is your baby :)

Something missing is probably the version(s) of sugar the activity is
compatible with.

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Dan Williams-4
In reply to this post by Marco Pesenti Gritti
On Fri, 2006-09-01 at 11:22 +0200, Marco Pesenti Gritti wrote:

> Bert Freudenberg wrote:
> >
> > Am 01.09.2006 um 02:36 schrieb Dan Williams:
> >
> >> http://wiki.laptop.org/go/Activity_Bundles
> >>
> >> Comments welcome.  Especially from you, Blizzard, since easily
> >> installable and transferable activities is your baby :)
> >
> > You wrote: 'Each activity bundle must, in its root directory, contain
> > a file with the same name as the activity bundle, but ending in
> > ".info" rather than ".activity"'.
> >
> > IMHO a fixed name, like "activity.info" would be preferable.
> >
> > We could then rename the bundle, try different versions etc. without
> > needing to touch the inside. Also it would be simpler to script:
> >
> >     grep default_type *.activity/activity.info
> >
> > It's common practice as well, like JAR's manifest.mf or OS/X bundle's
> > info.plist.
>
> Dan,
>
> I tend to agree with Bert reasoning here.

Ok, will fix.

>
> More comments:
>
>  >These should always be stored in an activity-specific directory in the
> user's sugar profile, available >through the SUGAR_PROFILE environment
> variable
>
> Currently SUGAR_PROFILE is the profile name and the actual profile path
> is ~/.sugar/$SUGAR_PROFILE. We might specify this or have the session to
> export SUGAR_PROFILE_PATH based  on SUGAR_PROFILE.

I'm a bit hesitant to rely on hardcoded magic paths like ~/.sugar :)  We
may not end up calling this thing "sugar".  So I'd prefer to have the
full path to the profile specified in the environment variable.

> >icon = activity-web
> >This key is optional. It points to the activity's icon. The
> >icon is first searched for in the >activity bundle's root directory, and
> >if not found, is looked up in the current GTK icon >theme. It cannot
> >contain a path.
>
> What is the actual icon filename when looking up the bundle directory?
> $icon + '.svg' or should the field be icon = activity-web.svg in that case?

Should make this more clear.  To be honest, I think we should restrict
icons to be SVG, and require them to use the CSS styles we specify so we
can enforce a consistent visual style.  That way, we don't get into the
whole file extension mess, and where if you specify the extension it's
looked up in the activity first, etc.  If the visual characteristics of
icons in the panel are important, which they are, we should enforce
that.

> We also need to specify the icon format (maybe thinking a bit more to
> the css properties and possibly improving them). Something I was
> thinking is that the css should be external, only the class attributes
> should be required in the svg files... librsvg does not support external
> css yet but we can just add the whole css to the svg file after loading.

Sounds good.  We should then reject icons that don't have every element
be part of one of the CSS classes Sugar specifies.

> >default_type = _web_olpc._udp
> >Each activity must have a default type. This must follow the
> >mDNS specification for serivce types and must be globally unique. This
> >key is required. It is used as the service type for the mDNS service
> >when the activity is shared.
>
> Do we actually want to make this required? There are activities that
> might not be sharable (terminal for example) or that haven't implement
> sharing yet.

They should probably all have a default type though...  the other
alternative is to reverse the D-Bus service name, s/./_/ and use that as
the default type.  I'm not sure that having two such unique identifiers
is useful.  The simpler the better.  We also have to think about how
we're presenting this to kids when they make their own activities.

>  >show_launcher = yes
>  >This key is optional. If specified, it indicates that the activity
> should show in the Sugar <http://wiki.laptop.org/go/Sugar> panel
>  >launcher, represented by the activity's icon. If specified, the 'icon'
> key must also be specified.
>
> Since it's optional might be worth adding that it defaults to no.

Per your next mail, I'll default it to yes.

Dan

> Marco

Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti

> Should make this more clear.  To be honest, I think we should restrict
> icons to be SVG, and require them to use the CSS styles we specify so we
> can enforce a consistent visual style.  That way, we don't get into the
> whole file extension mess, and where if you specify the extension it's
> looked up in the activity first, etc.  If the visual characteristics of
> icons in the panel are important, which they are, we should enforce
> that.
>
>  

I think it make sense, yeah.

>> We also need to specify the icon format (maybe thinking a bit more to
>> the css properties and possibly improving them). Something I was
>> thinking is that the css should be external, only the class attributes
>> should be required in the svg files... librsvg does not support external
>> css yet but we can just add the whole css to the svg file after loading.
>>    
>
> Sounds good.  We should then reject icons that don't have every element
> be part of one of the CSS classes Sugar specifies.
>
>  
>>> default_type = _web_olpc._udp
>>> Each activity must have a default type. This must follow the
>>> mDNS specification for serivce types and must be globally unique. This
>>> key is required. It is used as the service type for the mDNS service
>>> when the activity is shared.
>>>      
>> Do we actually want to make this required? There are activities that
>> might not be sharable (terminal for example) or that haven't implement
>> sharing yet.
>>    
>
> They should probably all have a default type though...  the other
> alternative is to reverse the D-Bus service name, s/./_/ and use that as
> the default type.  I'm not sure that having two such unique identifiers
> is useful.  The simpler the better.  

It might be a good idea, yeah.

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti
In reply to this post by Dan Williams-4
Maybe id should actually be type_id to avoid confusion with the actual
activity (unique per each instance).

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti
Marco Pesenti Gritti wrote:
> Maybe id should actually be type_id to avoid confusion with the actual
> activity (unique per each instance).
>

Or we could leave this id in the bundle info and have something like
get_bundle_id in the activity api.

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti
Marco Pesenti Gritti wrote:
> Marco Pesenti Gritti wrote:
>> Maybe id should actually be type_id to avoid confusion with the
>> actual activity (unique per each instance).
>>
>
> Or we could leave this id in the bundle info and have something like
> get_bundle_id in the activity api.

In the registry api itself we should probably use bundle rather than
activity which is ambiguous.

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Jacob Rus-5
In reply to this post by Dan Williams-4
Dan Williams wrote:
> http://wiki.laptop.org/go/Activity_Bundles
>
> Comments welcome. Especially from you, Blizzard, since easily
> installable and transferable activities is your baby :)
>
> Dan
Apple's very similar application bundles may be a useful inspiration
here.  They are quite well [documented][1] at Apple's developer
website.  In particular, there are a few things in OS X application
[info.plist files][2] that may be useful for OLPC info files.

 1. Info.plist files have both a monotonically increasing integer
    version (CFBundleVersion), and a human-readable version string,
    (CFBundleShortVersionString).
 2. Applications declare which file types they are able to open,
    and which icons to use for those file types.
 3. The LSMinimumSystemVersion key is used to indicate the minimum
    operating system version the application will run on.

Also, OS X handles all internationalization through ?LangName?.lproj
folders inside the resources folder for the application bundle.  These
contain localized versions of every string applicable to the info.plist
files, in files called InfoPlist.strings, and other internationalized
strings in a file called Localizable.strings.  This way isn't
necessarily better, but keeping all the localized strings for a
particular language for a particular application in one place, instead
of leaving some of them in the main info file, and others elsewhere,
seems like a good idea to me.

In general, what you have looks pretty good to me. :)

-Jacob

[1]:
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/index.html#//apple_ref/doc/uid/10000123i
[2]:
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/index.html#//apple_ref/doc/uid/10000170i
Reply | Threaded
Open this post in threaded view
|

Re: RFC: activity bundles

Mike Hearn-3
In reply to this post by Dan Williams-4
On Thu, 31 Aug 2006 20:36:27 -0400, Dan Williams wrote:
> http://wiki.laptop.org/go/Activity_Bundles
>
> Comments welcome.  Especially from you, Blizzard, since easily
> installable and transferable activities is your baby :)

Hey,

A few assorted thoughts:


* Host Versioning: I think it may be better to let activities
  handle this themselves. Consider an activity that can run on
  Sugar v1 but will use some new APIs added in Sugar v2 if
  they are available. If this (critical) information is
  expressed via bundle metadata then Sugar itself will end up
  displaying a generic message like:

    "This activity is designed for a newer laptop. It will run on
     yours but with reduced functionality"

  But that might not be right! If the activity code itself takes
  care of this (maybe helped by some convenience apis) then it can
  take a more appropriate action. Maybe the new APIs it needs
  improve performance or looks but nothing else. It would be dumb
  to scare the user by mentioning this. On the other hand maybe
  some critical feature won't work unless Sugar v2 is present.
  It would be worth notifying the user exactly what won't work,
  in that case.

  None of this is possible if Sugar itself checks activity host
  versioning.


* There is no convenient API to refer to binary-relative files
  on Linux. For autopackage we now have a simpler approach to
  making relocatable software - a file descriptor with a pre-determined
  number is opened before main() runs pointing to the right
  prefix. Software can then simply open("/proc/self/fd/200/myfile.png")
  I think this is better than relying on the current working dir
  being set ... the program may want to change it during operation.

  This also solves problems with the ton of legacy code that does
  not ever expect to be outside of /usr


* SVG icons take a lot of CPU time to render, relative to uncompressed
  bitmaps. Maybe there should be some support for noticing if they
  change and caching them?


* XML is fully specified and the edge cases are handled whereas an
  INF/.desktop style derivative isn't really. I know XML is ugly
  but still ....


Hope that helps!

thanks -mike
 

Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Marco Pesenti Gritti
In reply to this post by Jacob Rus-5
Jacob Rus wrote:

> Dan Williams wrote:
>> http://wiki.laptop.org/go/Activity_Bundles
>>
>> Comments welcome. Especially from you, Blizzard, since easily
>> installable and transferable activities is your baby :)
>>
>> Dan
> Apple's very similar application bundles may be a useful inspiration
> here.  They are quite well [documented][1] at Apple's developer
> website.  In particular, there are a few things in OS X application
> [info.plist files][2] that may be useful for OLPC info files.
>
> 1. Info.plist files have both a monotonically increasing integer
>    version (CFBundleVersion), and a human-readable version string,
>    (CFBundleShortVersionString).

I tend to think this would be useful. I don't think we should expose it
during a normal installation process but when things breaks or there are
anomalities, it would be preferable to show a human readable version to
the user then an integer.

> 2. Applications declare which file types they are able to open,
>    and which icons to use for those file types.

I think the associations between files and activities in sugar will not
be usually MIME based.
There is still the case of files downloaded from the web, which I'm not
sure how to handle yet (pdf for example). Maybe this could work for that
case but I want to avoid to get in the business of file types
association editing at any cost :)

> 3. The LSMinimumSystemVersion key is used to indicate the minimum
>    operating system version the application will run on.
>

Yeah I think I brought this up with Dan too. Indicating a minimum
version or an exact one depends on which kind of ABI policy we decide to
adopt.

> Also, OS X handles all internationalization through ?LangName?.lproj
> folders inside the resources folder for the application bundle.  These
> contain localized versions of every string applicable to the
> info.plist files, in files called InfoPlist.strings, and other
> internationalized strings in a file called Localizable.strings.  This
> way isn't necessarily better, but keeping all the localized strings
> for a particular language for a particular application in one place,
> instead of leaving some of them in the main info file, and others
> elsewhere, seems like a good idea to me.

Yeah, Dan was considering something similar if I'm not mistake.

Thanks,
Marco
Reply | Threaded
Open this post in threaded view
|

Re: RFC: activity bundles

Marco Pesenti Gritti
In reply to this post by Mike Hearn-3
Mike Hearn wrote:

> On Thu, 31 Aug 2006 20:36:27 -0400, Dan Williams wrote:
>  
>> http://wiki.laptop.org/go/Activity_Bundles
>>
>> Comments welcome.  Especially from you, Blizzard, since easily
>> installable and transferable activities is your baby :)
>>    
>
> Hey,
>
> A few assorted thoughts:
>
>
> * Host Versioning: I think it may be better to let activities
>   handle this themselves. Consider an activity that can run on
>   Sugar v1 but will use some new APIs added in Sugar v2 if
>   they are available. If this (critical) information is
>   expressed via bundle metadata then Sugar itself will end up
>   displaying a generic message like:
>
>     "This activity is designed for a newer laptop. It will run on
>      yours but with reduced functionality"
>
>   But that might not be right! If the activity code itself takes
>   care of this (maybe helped by some convenience apis) then it can
>   take a more appropriate action. Maybe the new APIs it needs
>   improve performance or looks but nothing else. It would be dumb
>   to scare the user by mentioning this. On the other hand maybe
>   some critical feature won't work unless Sugar v2 is present.
>   It would be worth notifying the user exactly what won't work,
>   in that case.
>
>   None of this is possible if Sugar itself checks activity host
>   versioning.
>
>
>  

I think both should be possible. We don't know how the activities ABI
will be changing yet and how much work will be necessary to support
multiple versions of the platform (even degradating functionalities). I
think in some cases requiring a certain platform version to install the
activity will be the simpler solution.

> * SVG icons take a lot of CPU time to render, relative to uncompressed
>   bitmaps. Maybe there should be some support for noticing if they
>   change and caching them?
>
>  

Yep, I think so.

> * XML is fully specified and the edge cases are handled whereas an
>   INF/.desktop style derivative isn't really. I know XML is ugly
>   but still ....
>  

Hmm not sure. Desktop files has some simple specification we might want
to inherit:
http://standards.freedesktop.org/desktop-entry-spec/latest/
Glib key files implementation is based on this.

Marco
Reply | Threaded
Open this post in threaded view
|

RFC: activity bundles

Dan Williams-4
In reply to this post by Marco Pesenti Gritti
On Mon, 2006-09-04 at 11:40 +0200, Marco Pesenti Gritti wrote:

> Jacob Rus wrote:
> > Dan Williams wrote:
> >> http://wiki.laptop.org/go/Activity_Bundles
> >>
> >> Comments welcome. Especially from you, Blizzard, since easily
> >> installable and transferable activities is your baby :)
> >>
> >> Dan
> > Apple's very similar application bundles may be a useful inspiration
> > here.  They are quite well [documented][1] at Apple's developer
> > website.  In particular, there are a few things in OS X application
> > [info.plist files][2] that may be useful for OLPC info files.

Right; I've worked with Apple bundles before quite a bit and thought
about them for this too.

> > 1. Info.plist files have both a monotonically increasing integer
> >    version (CFBundleVersion), and a human-readable version string,
> >    (CFBundleShortVersionString).
>
> I tend to think this would be useful. I don't think we should expose it
> during a normal installation process but when things breaks or there are
> anomalities, it would be preferable to show a human readable version to
> the user then an integer.

Good point.  Hopefully we'll never have to show that; we should have
very well-defined failure cases here, and that was the point of a
single, unambiguous build number.  If the type_id and version number of
an activity are the same as another activity that's being installed,
then the new installation fails.  Only if the build number were higher,
or of course if the type_id is different, does the new one get
installed.

Another thing that will go into the spec is arbitrary directory names.
The activity _cannot_ rely on the activity bundle directory name, as
Sugar will change that name at will to prevent activity bundle
conflicts.

> > 2. Applications declare which file types they are able to open,
> >    and which icons to use for those file types.
>
> I think the associations between files and activities in sugar will not
> be usually MIME based.
> There is still the case of files downloaded from the web, which I'm not
> sure how to handle yet (pdf for example). Maybe this could work for that
> case but I want to avoid to get in the business of file types
> association editing at any cost :)

Right; there won't be very tightly-defined type/creator stuff; and
hopefully we won't be displaying data by a document icon either.

> > 3. The LSMinimumSystemVersion key is used to indicate the minimum
> >    operating system version the application will run on.
> >
>
> Yeah I think I brought this up with Dan too. Indicating a minimum
> version or an exact one depends on which kind of ABI policy we decide to
> adopt.
>
> > Also, OS X handles all internationalization through ?LangName?.lproj
> > folders inside the resources folder for the application bundle.  These
> > contain localized versions of every string applicable to the
> > info.plist files, in files called InfoPlist.strings, and other
> > internationalized strings in a file called Localizable.strings.  This
> > way isn't necessarily better, but keeping all the localized strings
> > for a particular language for a particular application in one place,
> > instead of leaving some of them in the main info file, and others
> > elsewhere, seems like a good idea to me.
>
> Yeah, Dan was considering something similar if I'm not mistake.

Yeah; since localization is activity-defined (GTK and pygtk apps would
use gettext, but I'm sure other methods will crop up) the activity
bundle spec only defines where to get the activity name localizations
from.  To this end there I'm going to update the proposal to include
individual activity name localization files in a separate directory.
Cramming them all into one file, as Blizzard pointed out, is madness :)

Dan

> Thanks,
> Marco
> _______________________________________________
> Sugar mailing list
> [hidden email]
> http://mailman.laptop.org/mailman/listinfo/sugar