SqueezeWiki - centralised responstory forapplets/wallpapers/sounds

[Triode]

Has anyone done any more work on the SqueezeWiku concept?
[http://wiki.slimdevices.com/index.php/SqueezeWiki]

I was thinking that we could start with the server/controller support
necessary to allow centralised distribution of applets/wallpaper/sounds to
squeezeplay. Especially for 7.3 where squeezeplay will be used on the
desktop, it would be useful to have built in support for 3rd party
customisations using a repository maintained centrally.

In the first instance I suggest a manually maintained opml resource file
which is hosted on the slim web site somewhere. This would define the
resources available and the urls of where to download them from. The long
term aim would be to automatically generate this from the wiki, but I think
it could be manually maintained at present.

It would be relatively trivial to extend the current JiveExtras plugin to
fetch this opml file and use the content to respond to comet requests for
applet/wallpaper/sound lists and so use the current mechanisms in
squeezeplay to download and install the extras. This should also be able to
be used on SN to allow the full set of centralised resources to be available
for SN connected squeezeplay.

If this proves successfull then we should look at a similar mechanism to
automate downloading of plugins to SC and as a third phase for the backend
to generate the opml resource files automatically from the wiki (but there's
lots more questions here about authentication etc, so I think a manual
process would be best first)

Thoughts?

[Tom/Richard - this needs zipfilter to work on the windows version of
squeezeplay, currently it is not built]

Adrian

[dean]

Adrian,

On Oct 19, 2008, at 5:34 AM, Triode wrote:
> I was thinking that we could start with the server/controller support
> necessary to allow centralised distribution of applets/wallpaper/
> sounds to
> squeezeplay. Especially for 7.3 where squeezeplay will be used on the
> desktop, it would be useful to have built in support for 3rd party
> customisations using a repository maintained centrally.
Great!!!!!

> In the first instance I suggest a manually maintained opml resource
> file
> which is hosted on the slim web site somewhere. This would define the
> resources available and the urls of where to download them from.
> The long
> term aim would be to automatically generate this from the wiki, but
> I think
> it could be manually maintained at present.
That sounds like a great start.

> It would be relatively trivial to extend the current JiveExtras
> plugin to
> fetch this opml file and use the content to respond to comet
> requests for
> applet/wallpaper/sound lists and so use the current mechanisms in
> squeezeplay to download and install the extras. This should also be
> able to
> be used on SN to allow the full set of centralised resources to be
> available
> for SN connected squeezeplay.
>
> If this proves successfull then we should look at a similar
> mechanism to
> automate downloading of plugins to SC and as a third phase for the
> backend
> to generate the opml resource files automatically from the wiki (but
> there's
> lots more questions here about authentication etc, so I think a manual
> process would be best first)
>
> Thoughts?
A terrific move in the right direction.

> [Tom/Richard - this needs zipfilter to work on the windows version of
> squeezeplay, currently it is not built]
Bug 9762 filed.

[peterw]

If this proves successfull then we should look at a similar mechanism to
automate downloading of plugins to SC and as a third phase for the backend
to generate the opml resource files automatically from the wiki (but there's
lots more questions here about authentication etc, so I think a manual
process would be best first)

Thoughts?

I think a nice relational database would be a better choice for the backend than a wiki. Not only would it be cleaner, but you could more easily apply security to it (e.g., only allow contributors [and Logitech staff?] the ability to edit info about their offerings).

This gets back to issues we discussed last summer, see
http://forums.slimdevices.com/showth...t=36733&page=3
and following. I think Dan Sully was on the right track with Firefox-like mechanisms for updates, and I think you really need a nice relational DB / XML model to do it well.

-Peter

[Triode]

> I think a nice relational database would be a better choice for the
> backend than a wiki. Not only would it be cleaner, but you could more
> easily apply security to it (e.g., only allow contributors [and
> Logitech staff?] the ability to edit info about their offerings).

At present I'm thinking we don't include the backend in the first
itteration. I agree there are lots of conflicting requirements here, from
allowing authors to update their own version to validating credentials etc.
I'm also proposing looking at jive first as I view this as a safer target
(malious attackes can do less damage) than for the server.

> This gets back to issues we discussed last summer, see
> http://forums.slimdevices.com/showth...t=36733&page=3
> and following. I think Dan Sully was on the right track with
> Firefox-like mechanisms for updates, and I think you really need a nice
> relational DB / XML model to do it well.
>

My thought is that we define an xml format for a repository directory.
There will be one Slim hosted repository, but users can add other ones (for
applets which Slim does not endorse etc)
The server/SN will download the respository xml file and use this to
response to the comet applet installer request.

Each entry will contain at least:
name
type = applet|wallpaper|sounds etc
version
minVersion & maxVersion (of jive)
desciption - url for text description (to allow localised descriptions
from a hosted remote file)
homepageURL -
URL - url to for download from

jiveAPIVersion - not sure about this - there's an api version which is
constantly 1....

This is loosely styled after the content of install.xml files for plugins.
I am assuming that authors will create an xml file for their own applets and
these get merged into the repro xml feed. Later on authors may be able to
automatically upload them.

[Tom Wadzinski]

Adrian,


> [Tom/Richard - this needs zipfilter to work on the windows version of
> squeezeplay, currently it is not built]
Bug 9762 filed.

I just added zipfilter as part of the windows build. Bug 9762 closed.

[peterw]

Adrian, that sounds good. I wonder if you could:

1) make a wiki template for that XML info, so a developer could create a wiki page and just make sure it has a section that looks like:

Begin_repository_info
name.EN = My applet
name.DE = Mein Applet
type = applet
version = 1.1
minVersion = 1234
maxVersion = 5678
URL = http://blah.example.com/myapplet-1.1.zip
description.EN = This is good.
description.DE = Das ist gut.
End_repository_info

and parse that to create the repository XML. Your repository creation process could simply search for wiki content including "Begin_repository_info" and parse the text. Authors could put that info anywhere on the page, allowing them to have "pretty" info up top. This should even allow authors to include multiple repository_info blocks if they had different releases for different Jive versions, or wanted a single wiki page to serve for multiple items.

2) since the wiki requires logins... when the tool that creates the repository XML first notices a new app/sound/wallpaper/etc., it could note the wiki username that created that resource's wiki page. It would remember/cache this info and at the very least refuse to use information in updates to the page unless those updates were made by the original wiki page author. Better still would be to always retrieve the latest version of the wiki page that had been saved by the original author, so there'd be no risk of some other wiki author messing up the info.

BTW, I think Jive could be a really appealing target, especially if it runs Jive as the root user (obviously I haven't SSHed to my Controller in a while). I expect an attacker could deliver all kinds of trojan code, and have the Lua applet write the attack code to the Controller filesystem, launch the attack code, and probably hack init.d/inittab to ensure the malware runs even after Controller reboots. The Controller may not be a very powerful computer, but it's on the network 24x7 and isn't going to have any anti-spyware protection. Could be really interesting if the wlan interface could go into promiscuous mode and be used to sniff & decrypt (thanks to Jive knowing the WPA key) local wifi traffic.

-Peter

[erland]

2) since the wiki requires logins... when the tool that creates the repository XML first notices a new app/sound/wallpaper/etc., it could note the wiki username that created that resource's wiki page. It would remember/cache this info and at the very least refuse to use information in updates to the page unless those updates were made by the original wiki page author. Better still would be to always retrieve the latest version of the wiki page that had been saved by the original author, so there'd be no risk of some other wiki author messing up the info.

Just remember that there might be cases where several developers might contribute to the same plugin/applet. Another situation is where a plugin is maintained by one developer and he ends the development and another developer takes over the maintenance.

[erland]

My thought is that we define an xml format for a repository directory.
There will be one Slim hosted repository, but users can add other ones (for
applets which Slim does not endorse etc)
The server/SN will download the respository xml file and use this to
response to the comet applet installer request.

This is loosely styled after the content of install.xml files for plugins.

If it can't be exactly as the install.xml format I would suggest that you try to extend it with things that can be incorporated in future versions of the install.xml format.

The reason is that it is nice if the plugin/applet developers only have to learn a single format and it also makes sense to have same format since you can install Jive applets in SqueezeCenter where they would have to use the standard install.xml format. As I've understood it, Jive applets installed in SqueezeCenter will be automatically downloaded and installed on the Controller.

[dean]

Sounds good. Does the "type" indicate just where it goes in the UI
and that all the different types are packaged the same?

Or are we talking about different types of packages?


On Oct 20, 2008, at 12:06 PM, Triode wrote:

>> I think a nice relational database would be a better choice for the
>> backend than a wiki. Not only would it be cleaner, but you could more
>> easily apply security to it (e.g., only allow contributors [and
>> Logitech staff?] the ability to edit info about their offerings).
>
> At present I'm thinking we don't include the backend in the first
> itteration. I agree there are lots of conflicting requirements
> here, from
> allowing authors to update their own version to validating
> credentials etc.
> I'm also proposing looking at jive first as I view this as a safer
> target
> (malious attackes can do less damage) than for the server.
>
>> This gets back to issues we discussed last summer, see
>> http://forums.slimdevices.com/showth...t=36733&page=3
>> and following. I think Dan Sully was on the right track with
>> Firefox-like mechanisms for updates, and I think you really need a
>> nice
>> relational DB / XML model to do it well.
>>
>
> My thought is that we define an xml format for a repository directory.
> There will be one Slim hosted repository, but users can add other
> ones (for
> applets which Slim does not endorse etc)
> The server/SN will download the respository xml file and use this to
> response to the comet applet installer request.
>
> Each entry will contain at least:
> name
> type = applet|wallpaper|sounds etc
> version
> minVersion & maxVersion (of jive)
> desciption - url for text description (to allow localised
> descriptions
> from a hosted remote file)
> homepageURL -
> URL - url to for download from
>
> jiveAPIVersion - not sure about this - there's an api version
> which is
> constantly 1....
>
> This is loosely styled after the content of install.xml files for
> plugins.
> I am assuming that authors will create an xml file for their own
> applets and
> these get merged into the repro xml feed. Later on authors may be
> able to
> automatically upload them.
>
>
>

[peterw]

Just remember that there might be cases where several developers might contribute to the same plugin/applet. Another situation is where a plugin is maintained by one developer and he ends the development and another developer takes over the maintenance.

That'd add some complexity; a "contributors" value like

contributors = erland, peterw

Only modifications by a current contributor (by default, the page creator) would be acceptable. So you could create a page, add me as a contributor, and then I could remove you from the contributor list, effectively locking you out.

Would adding such logic be worth the trouble? For a jointly-maintained resource, I think the developers could coordinate & have the same person update that portion of the wiki page, so I imagine this'd mainly be useful for hand-offs. Even then, it might be easier to have the current owner email whoever runs the repo XML build process (Adrian? Matt?) & have them edit the cached data to change ownership.