in the context of designing the new SilverStripe 3.0 I would like to kick of a discussion about a Module Manger and share some thoughts about how I would picture it. In the fashion of the http://open.silverstripe.org/wiki/development/NewDataMapper I created a page in the wiki and encourage people comment on it here in the dev list. Here it is [drum roll]:
http://open.silverstripe.org/wiki/development/ModuleManager
Cheers
Andy
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
Andreas, great work and thanks for putting up some thoughts.How did you see this working with the notion of a website bridging various environments, such as development, testing, and production?
--
Web developers? Well they don't really need a module manager do they?
They usually know how to use source code management softwares, but
they wonder if that version of that particular module will fit well in
that SS installation, or play along well with these other modules. So
they clone the code, test thoroughly, and deploy when happy. That's in
an ideal world of course. Still the dependency manager described
earlier would be priceless in that respect. And using a cli for
installing/upgrading/removing modules could be interesting for
developers.
But many web developers work for clients who asked for a cms for a
good reason usually (as opposed to static html like 10 years ago) :
getting as much control over their website a possible. I don't know if
you are like me, but 90% of my clients are small to very small
businesses, hosting their website somewhere on a shared server. They
are quite keen on installing a module, widget or a theme, but yeah cli
is not their cup of tea (they don't even have access to it anyway) but
they are now comfortable with SS backend.
My vote is to leave the Module Management to the developers and leave managing content to the site maintainers.
An alternate idea would be functionality in SS that listed and linked to the modules available on ss.org for developers to have quick access to and maybe a download builder on ss.org so you could select all the modules you wanted and then download them in 1 package file. Then, for the site maintainers, it could use the proposed module metadata to call home and check if there were updates to the core or modules and inform the maintainer if they're critical or not. Then they would contact their developer to do the necessary upgrades. It would provide more of an impetus for repeat work for us developers ;-)
In my experience, most of the people maintaining these websites barely know how to use a computer, let alone upgrade software. Upgrading web software by a layman is risky business to say the least.
Matt
i've been following the discussion closely over last days. thanks for the many good ideas. i'm on leave until early march and i will then catch up on the thread. since there has been so much positive response about the mm i am confident that we will pull it off.
thanks
andy
a. does this exist already?ORb. can you please provide any lists? (Silverstripe People, maybe you can provide an export from your website????)
I can provide this list as XML / JSON / WHATEVER so that people can retrieve it to their own websites, etc...
Thanks for your message. Are you saying that there is a RESTFul service operating or that it can be turned on?
Yeah, I think the initial focus will be to create a PHP/sake based API, on top of which UIs can be built.
The function of the silverstripe.org website in any module manager will be to deliver some kind of json/XML/csv/whatever index.
It's not clear at this stage what silverstripe.org/modules will be come once the application itself has its own module manager. It's feature-set *may* be reduced a little but I would expect there to still be value in having a standalone module browser, for newcomers to the platform.
> Also, it would be great to start doing some analytics on the modules.
> If you could track the number of downloads and add tags to modules,
> that would open up a whole new world to a frontend module manager that
> could work with some level of intelligence and dynamism, rather than
> getting stuck in the search/browse pattern.
Yeah I agree that as the number of modules grows, we need better tools to sort through them.
The module manager is going to be increasingly important for managing things like:
- dependencies between modules
- knowing which modules need upgrade
- knowing which versions of which module work with which versions of Sapphire (and SilverStripe CMS, and forum, and...)
Most O/Ses and development platforms have some kind of package manager, because they're a good idea.
On sites that I develop, I'm unlikely to enable any kind of module installation user interface on production sites. It's more of a development / configuration tool. But some people using SilverStripe in more of a self-service manner might find the module UI useful.
That said, the whole 'I installed a module and now the module manager is broken' risk is something we're going to need to address, most likely by some kind of rollback support in the manifest.
In summary, my recommendation would be to abandon the "module manager" as discussed here (if I understand it right) and focus this energy on:
you enter a list of svn / git external addresses of the modules you are using.
b. it works out any problems and list recommendations (e.g. if you use ecommerce 0.5, you must also use payment 0.8 - you have not included this)
> Something to consider, and I'm not sure if there's enough of a performance benefit for...
>
> Has anyone investigated whether combining modules together provides any form of speed increase at all? I've got a couple of projects with over 20 required modules, and I'd be interested to know if that has a noticeable performance impact or not.
The only significant impact would come from the number of decorators.
> Aside from that, as a module developer, it'd be really nice to have a tool that easily allows me to create a 'release' version of a module that includes any relevant dependencies
Why? If the module manager will install the dependency for you I don't see the benefit. What if someone installs 2 modules which both have the same dependency? If it's just a great idea, why doesn't apt-get do it?
The easiest way would be to try not to have maximum allowed versions,
ie Foo requires Bar2.3 or higher.
In the case Foo only works with Bar2.3-2.9, you'd be prevented from
installing/updating to Bar3.0 or anything that depends on it, until
Foo is removed or updated to work with Bar3.0...
--
The project has begun...
That way, developers can more easily resolve module duplication.
In the case of managing decency conflicts - this is what makes constructing such an algorithm nontrivial. Some kind of heuristic search will probably be the best idea. Time to crack open my AI textbooks!