I notice a few other competitor CMS's, Portal and blog tools have update tools. That is a module which updates the core and module and also some of them download modules or applications for the CMS.

I am going to write this for 2.6 so we have a system where it will download core patches and updates as well as applications for XOOPS that have been mounted on it. It will also support the downloading of Themes and Patches.

What i will be interested in if someone is interested in being the Quality Control Officer for it (Ideally someone like cesag who is proactive in testing modules would volunteer). The role will give you a slightly different access to the module which allows you to check the packaging and quanlity of a module or core release and approve it to be farmed out via API (X-REST) to the sites that will also have notification that an update is available.

Due to the size of the modules etc, older versions will be depreciated on the farm and deleted. However it will involve creating a username on the system once it is created and then creating an entry in the core, module, theme modules which will create a folder to upload your files unzipped to on a public ftp, where they will be once you have notified the upload is finished copy and mount the files to the queue area for quality control then release to public.

File structure will be like so on the public ftp:

themes/
modules/
core/

inside these primary folders you will find a folder say your module is called 'inventor' it would be:

modules/inventors/

where it follows the standard packaging method in xoops which MUST BE USED!! of

modules/inventors/docs
modules/inventors/htdocs
modules/inventors/extra
modules/inventors/upgrades

htdocs will have the following folder paths under it as per your packaging

modules/inventors/htdocs/class
modules/inventors/htdocs/kernel
modules/inventors/htdocs/Frameworks
modules/inventors/htdocs/include
modules/inventors/htdocs/modules
modules/inventors/htdocs/themes
modules/inventors/htdocs/xoops_data
modules/inventors/htdocs/xoops_lib

The upgrade version you are upgrade from, the last release version, any files which have changed are in this; previous upgrade version will not be deleted in depreciating an upload for stepping up multiple version in small file downloads the folder structure of this version say it is going from 3.01 to 3.02 would be like so:

modules/inventors/upgrades/3.01-3.02/htdocs/class
modules/inventors/upgrades/3.01-3.02/htdocs/kernel
modules/inventors/upgrades/3.01-3.02/htdocs/Frameworks
modules/inventors/upgrades/3.01-3.02/htdocs/include
modules/inventors/upgrades/3.01-3.02/htdocs/modules
modules/inventors/upgrades/3.01-3.02/htdocs/themes
modules/inventors/upgrades/3.01-3.02/htdocs/xoops_data
modules/inventors/upgrades/3.01-3.02/htdocs/xoops_lib


inside these primary folders you will find a folder say your theme is called 'messagers' it would be:

theme/messagers/

where it follows the standard packaging method in xoops which MUST BE USED!! of

theme/messagers/docs
theme/messagers/htdocs
theme/messagers/extra

htdocs will have the following folder paths under it as per your packaging

theme/messagers/htdocs/class
theme/messagers/htdocs/kernel
theme/messagers/htdocs/Frameworks
theme/messagers/htdocs/include
theme/messagers/htdocs/modules
theme/messagers/htdocs/themes

inside these primary folders you will find a folder say your core is called '2.6.0rc' it would be:

core/2.6.0rc/

where it follows the standard packaging method in xoops which MUST BE USED!! of

core/2.6.0rc/upgrades
core/2.6.0rc/complete
core/2.6.0rc/extra

complete will have the following folder paths under it as per your packaging

core/2.6.0rc/complete/htdocs/class
core/2.6.0rc/complete/htdocs/kernel
core/2.6.0rc/complete/htdocs/Frameworks
core/2.6.0rc/complete/htdocs/include
core/2.6.0rc/complete/htdocs/modules
core/2.6.0rc/complete/htdocs/themes
core/2.6.0rc/complete/htdocs/xoops_data
core/2.6.0rc/complete/htdocs/xoops_lib

upgrade will contain directors of versions for upgrading and the files for them in the same directory structure of the xoops ZIPS

ie. 2.5.0 - 2.5.5 version update would be in the folders like so, well the files being upgraded, the folder must be version-version after upgrade ie. '2.5.0-2.5.5':

core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/class
core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/kernel
core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/Frameworks
core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/include
core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/modules
core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/themes
core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/xoops_data
core/2.6.0rc/upgrade/2.5.0-2.5.5/htdocs/xoops_lib

Quote:

This is planed... and probably work is on he way already if he finished with the install, contact with redhead... he is working on such, in fact will be extended DM + options to update core, modules and to apply patches. Eg. if small bug is discovered - to apply patch only for the affected files, instead - whole new distribution package/update pack.

Quote:

There are several discussions regarding this subject, older will go to archive... someone else like u may want to adopt old, outdated module and to make it compatible for 2.5/2.6/2.7... or whatever version is next release.

But there are much more important things which should be solved, before the work on such project to start.

Modules Naming and Versioning

...and bitcero and trabis have to give answer about merging of they're frameworks, bitcero to fix some important problems....

Hey Simon,

The file structure looks good but I suggest simplification from what you have listed. We should actually probably have a discussion on the "proper" format of modules so that automated installation from a zip or tar.gz file is possible.

In relation to modules:

htdocs should not care what is inside it. Whatever is inside it should be copied to the htdocs folder on the system. Shouldn't matter if it is just simply contains "modules" or has other components such as "Frameworks" etc. Due to the potential for future expansion and addition of other folders there should be no limitation or hard coding on what folders are within htdocs.

xoops_data and xoops_lib should be contained in their own directories listed separately from htdocs thus enforcing the idea they should NOT be contained inside htdocs in the first place. The "preinstallation" system you are talking about here could then copy these directories to the proper locations without having to pull them out of the htdocs folder.

You could say similar things about the Core and Theme systems as well. I am thinking once we have an automatic system to install these the file formats will become much more important. I suggest we start a new thread to discuss the "Official" format of such so they can be added to Tutorials in the future.

Also I noticed as I am writing this DCrussader has already responded but I am actually looking into a system to do this in a simpler manner. However how you propose could be used in addition to the system I am in the design stages of now.

I am redoing the Install system at this point but I have had limited time with my oldest daughter Graduating HS. Plus I have been having issues getting the test site working on my laptop so I can work on it at work.

I will save a full discussion here but my intention is to create a new download module that will provide rss streams that will list modules, their versions and some other information. I am going to extend the module installation module Mamba has created to actually read these RSS streams and be able to install the modules as needed. The intent is to show it works and when it does work then hopefully this will be incorporated into 2.6 but this method will allow it to work easily with 2.5 as well. There is no reason why this couldn't be extended to themes as well but core installs really should be done by an external program.

Once I am successful with these I plan to create a stand alone installation/upgrade system that will incorporate what I learn and develop in these other systems. By providing RSS support directly like this it should be easy to add third party threads as well. This would be VERY similar to the Drupal system I have seen used.

Having said all that it would still be a good thing to be able to push modules onto your systems for either automatic installation or upgrade and perhaps what you are suggesting would work there. I have not really worked on that idea yet since I am trying to get past what I am doing now.

And yes, I think it is a very important thing for trabis and bitcero to get together and build a central framework for new modules.

I do hope to get back to working on the Install script in the next couple days. I had hoped to have it done by now but I have some setbacks time wise.

DC,

With THIS version of the install system I am not sure that patches and some other stuff will be incorporated. I am actually looking at a totally separate stand alone system once I have the module system working and have a new file download system working or atleast a secondary module that will provide the RSS feeds temporarily until I can build a new download module.


Rodney

Simon, please look into "Xoops Update" module.. I think, we could use something like this.

You can download it from here

We definitely should have automated Update functionality in 2.6.0, but let's see if we can leverage existing developments.

::[michael]::

Yeah that is exactly what I was thinking off? Any idea for hosting of it? How much room is on the xoops.org server and does it have an anonymous FTP? or somewhere we can set up a public FTP account to allow for people to upload the files.. Let me know and I will point xoops.asia at the name services for it so we can start building the update cloud.

I have finished my branch task for 2.6 and asked trabis to check it for me. It is ready for migration into the core copy.

Otherwise i can pick up 25Gb room on a Linux cloud, that seems to be running xortify.com quiet well for wholesale price of 30 AUD per year? What are your thoughts michael? I think we should host them both seperately. for security purposes, unless you can have a chat to surpass to see if they can host it for us?

WHat is the whois information for xoops.asia and xoops.mobi they are currently under my name but i can transfer them to a xoops account, i only had them cause i noticed they where available and thought to keep them for the team.

::[rodney]::

Thanks for your comments rodney, there would also be a frameworks folder, which would allow people to upload frameworks that you can select when you are scheduling a module to say when they are required to save space.

You will be able to make the install download the entire package off the update cloud via REST API. I don't want to install from ZIP as there is to many dependencies involved in it, i want people to upload the module into the folders as per the article above so I can store the files with for example a .dat after the file extension so they are not executable then copied across the API in base64 by the update/download module.

Once it is uploaded they will be emailed a link they run that will scan the public ftp point and copy all the files over to the mount point then scheduled for quality control and eventual availability on the API.

Quote:

I came back from holiday and I am ready to help

Quote:

cesag could you get in contact with me on skype, msn or yahoo thanks..

Quote:
The owner of http://www.ScriptUpdate.jp agreed graciously to include XOOPS Core and modules updates on that server. They have 100GB free storage, so there should be no problem for many years to come.

We'll probably start with XOOPS 2.6 once it's available, and with modules that pass the "Blue Move" test, i.e. they are working on XOOPS 2.5.5

We'll need a team that will help with uploading the Core and modules, and which will act as our Quality Team, i.e. before the modules get uploaded, it will be tested by the team and by the community, and only then uploaded.

Simon, thanks for the initiative in this area, and let's make it happen. Please also check the "Xoops Update" module, and if you have any improvement suggestions, please share them here, so we can communicate it to our Japanese friends from http://www.ScriptUpdate.jp

I'll look into updating the Admin GUI in this module.

Sure suits me fine, I just want to be competative.. What are we going to use Xoops.asia for then? anyway, so do you have an email address for those guys.. I will look at the module and rework it as best i can.. Don't worry about the Admin Gui michael i will do that as well, unless you have started otherwise email it to me.

It is the Asian Century at the moment, so we should do something with it, i have already paid for the first year hosting... But if they have 100Gb free host and a template to start with, who am i to reinvent the wheel.

Cesag volunteers for being a QC operator so you will have to make a Quality Control rank and put her in it... I will work with the scriptupdate.jp people to get the module and exchange method to scratch..

Can you send me a contact for them.. I should try and make contact with them in the mean time.

Simon

Hey how are you? We are currently discussing your service for inclusion with XOOPS 2.6 on xoops.org, this means there will have to be some changes like the use of a 'superuser' as most people are on shared hosting and don't have control of the superuser, it will make over 80% of the users with your module in the XOOPS 2.6 distribution unable to use the Update module with XOOPS 2.6 and later, it would be good to also have the 'install from scratch' option as well.

But that is okey, seeming I have been writting cloud solutions for spam called xortify, I suggest you take me onboard to come up with a REST API Solution to your updater module. I was in the process of planning one when michael beck (mamba) suggested we don't re-invent the wheel and just work with you lovely guys.

Could you also activate my account on your system 'wishcraft' is the username..

This is the thread for the discussion https://xoops.org/modules/newbb/viewtopic.php?topic_id=75205&post_id=346953#forumpost346953

You will find all my modules on http://code.google.com/p/chronolabs/downloads/list if you where having signup spamming then i suggest you install xortify it will stop all this.. but the module we will be using on your hopefully is X-REST my REST API for XOOPS.. Anyway talk soon, I will be on IM tomorrow after 12 (sydney australia)

MSN: lsd25@hotmail.com
Y!: sydsexymale@yahoo.com.au
Skype: wishcraft555