I'm wondering if you would want that code running on each CS installation, or maybe have just a link/iframe out to a marketplace running somewhere else? That would allow much easier management of the content - one scenario that comes to mind is if a seller's product is compromised or determined to be malicious, you'd want to pull it from the marketplace ASAP.
Maybe a compromise between the two - centrally serve an xml/binary feed that the CS install can grab/use, something like a yum/apt/etc repository. (note - I'm not suggesting add dependency functionality :) ) I don't think you want each potential seller contributing xml/graphics/code, or checking this into the source tree? I'd think what you want in the src tree is code for the client side, and maybe a web portal (I wouldn't want us to spend a ton of time coding this up unless this is a core feature moving forward): * Have a web UI where sellers can register/login and define/modify their products * Before products are listed in the feed, there's some sort of voting process (maybe moderate each seller until they've "proven" themselves over a release or two?) * Daily cron process generates the feed, places it somewhere accessible via http John On Jul 9, 2012, at 10:32 AM, Jie Feng wrote: > I would love to get folks' feedback on proposing a subproject under Apache > CloudStack, called MarketPlace. There are many ISVs, SaaS/PaaS vendors > providing value-added products and services on IaaS clouds. The goal is to > make their products more visible and easier to consume by anyone who deploys > CloudStack. It would also allow cloud admins to offer their own marketplace > to their users to get access to a variety of products and services that can > be used with CloudStack. > > Here is the idea: > * The subproject (let's call it MarketPlace for now) will consist > of source code for the CloudStack Marketplace user UI main page; a > product/service listing template; an admin portal; and a repository of > listing. Both the source code and listings will be part of the CloudStack > Marketplace distribution. > * Each listing will contain information about the > product/service, the user action needed to use the product/service, and > instructions for the admin to set up the product/service. Listings are > contributed by sellers (i.e. ISVs, SaaS/PaaS vendors). To include a listing > in the CloudStack MarketPlace distribution, the seller needs to place its XML > files, graphics and code in the designated folder within the subproject. > * When CloudStack is installed, the admin will have a choice to > install MarketPlace including all the pre-packaged listings. The admin can > then choose which listings to enable for the users to see. The admin may need > to follow seller instructions to get products/services set up. > * This is not a global marketplace for every CloudStack user. > Each CloudStack instance will have its own marketplace if the admin chooses > to install it. After CloudStack is installed, the admin should have the > capability to add, delete, enable, disable, and update the listings. If a > seller wants to add or update it listing for a specific CloudStack instance, > s/he needs to go through the admin. > > To keep it simple in the first phase, I propose to support two types of > listings only: SaaS/PaaS services and free image templates. Even though the > image template is free, the seller can still enforce licensing and charge a > fee within the application itself. To minimize product/service set up effort, > in the case of image template, seller should provide a publicly accessible > URL from which the image template can be downloaded. > > Future phases could include functions such as a seller listing publishing > portal, listing approval workflow, and usage reporting, etc. > > Jie
