Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 7 123 ... LastLast
Results 1 to 10 of 63
  1. #1
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    SqueezeWiki - centralised responstory forapplets/wallpapers/sounds

    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


  2. #2
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    SqueezeWiki - centralised responstory forapplets/wallpapers/sounds

    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.



  3. #3
    Quote Originally Posted by Triode View Post
    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
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  4. #4
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    SqueezeWiki - centralisedresponstoryforapplets/wallpapers/sounds

    > 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.



  5. #5
    Logitech Squeezebox Employee
    Join Date
    Jul 2008
    Posts
    201
    Quote Originally Posted by dean View Post
    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.
    Tom Wadzinski
    Logitech Developer - SqueezePlay

  6. #6
    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
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  7. #7
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,039
    Quote Originally Posted by peterw View Post
    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 Isaksson (My homepage)
    Developer of many plugins/applets

  8. #8
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,039
    Quote Originally Posted by Triode View Post
    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.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  9. #9
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    SqueezeWiki - centralisedresponstoryforapplets/wallpapers/sounds

    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.
    >
    >
    >

  10. #10
    Quote Originally Posted by erland View Post
    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.
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •