Jump to content

let's discuss IPB v4 architecture


majdi

Recommended Posts

Some of you might think its too early to discuss this subject my answer to them: whats the harm? so please be respectful and participate if you have something constructive to add :)
and lets limit to the main -big- subjects, this is not a feature request topic, its more of a brainstorming of the skeleton or the organisation of v4 release
i see the next major version architecture this way:

1- one main framework, ipb should no longer be the center of the community it should be a new independent app which includes the shared features between the different other apps: the plugin (app) manager, user and group manager, captcha, search, bbcodes, polls, attachments, WYSIWYG editor, skin and template manager, etc...
the key feature of the core should be the plugin manager, it should behave like the current app center but with few new features like a new version notifier that notifies even of new 3rd party apps, easy upgrades, etc...

2- + the different apps including IPB itself.

3- upgrading the forum should not break modifications done to the different apps (like skin modifications)

4- IP.Content should by the time of v4 release become a fully featured CMS, easy to use by none coders.

5- more and more inline moderation and the possibility to quote the selected text for example in one app and use it in another.

those are my ideas for the time being, i hope i explained them well enough :blush:
lets discover yours :)

Link to comment
Share on other sites

I'd rather have modifications and the modification community grow to build up badly needed things. Most of what you said is too general to say much about. This time though, I'm not updating to such a jump in versions till the bitter end.

Link to comment
Share on other sites


I don't like the first idea, the forum itself should still be the main thing :rolleyes:




Disagree - surely any app should be stand-alone.

i.e. if we want to run an extra IP.Nexus and do not need a forum, why should we have to purchase a forum as well? This opens up the product to a new market.

In any case would 3.5 not be the next major release?
Link to comment
Share on other sites

I think you may have some misconceptions about IP.Board's current architecture.

IP.Board uses completely object oriented programming, and is split into applications. The "forums" are simply an application which can be disabled. In fact, our website, invisionpower.com is running IP.Content with no forums attached (it is a separate installation, on a different server, to these company forums) - we simply turned off the forums and made IP.Content the default application - there is nothing special about this setup and can be done out of the box.
Applications make use of "extensions" which are standalone files that can be added and removed to applications. These enable things like attachments, notifications, reputation, etc. which are shared features. Our addon applications (IP.Blog, IP.Gallery, etc.) all use these shared features, yet there is no code in IP.Board at all that is specific to Blog or Gallery.

You can upgrade applications independently without affecting the others. We on these forums have IP.Board, all the applications and several "third party" apps (Tracker, Links) all of which have different development cycles and we upgrade independently.
If you have an application which breaks on a minor upgrade - that application is not making use of things like the hooks system, which it probably could to avoid this issue.


There are some things which textbook examples of modular applications would suggest which we deliberately don't do for technical reasons of a scalable and distributable application (for example, one might suggest one database table for posts, and comments in Blog, Gallery, Downloads, etc. but doing this you could easily hit some MySQL or OS limitations on tables/file sizes) but by and large, I'm confused as to what specifically you're suggesting we change... most of what you suggest is a description of what we already do.
The next major versions will definitely be 3.2, and then likely 3.3, etc - 4.0 is something we're not going to be thinking about any time soon.

Link to comment
Share on other sites


Some of you might think its too early to discuss this subject my answer to them: whats the harm? so please be respectful and participate if you have something constructive to add :)


and lets limit to the main -big- subjects, this is not a feature request topic, its more of a brainstorming of the skeleton or the organisation of v4 release


i see the next major version architecture this way:



1- one main framework, ipb should no longer be the center of the community it should be a new independent app which includes the shared features between the different other apps: the plugin (app) manager, user and group manager, captcha, search, bbcodes, polls, attachments, WYSIWYG editor, skin and template manager, etc...


the key feature of the core should be the plugin manager, it should behave like the current app center but with few new features like a new version notifier that notifies even of new 3rd party apps, easy upgrades, etc...



2- + the different apps including IPB itself.



3- upgrading the forum should not break modifications done to the different apps (like skin modifications)



4- IP.Content should by the time of v4 release become a fully featured CMS, easy to use by none coders.



5- more and more inline moderation and the possibility to quote the selected text for example in one app and use it in another.



those are my ideas for the time being, i hope i explained them well enough :blush:


lets discover yours :)




6- Adding ALL possibly available approved plugins should be as simply as doing an ADDON like in FIREFOX !
(split revenues with IPS and developer if fee based)
Link to comment
Share on other sites


I think you may have some misconceptions about IP.Board's current architecture.




I am not sure I do - am aware that on the main site, there are no forums a such, well there are (assume at http://www.invisionpower.com/ccs_forums_install/index ), but they are not used.

My point was about requiring a purchase of IP.Board if it is not used - currently I do not believe that is possible - even for say IP.Content.




The next major versions will definitely be 3.2, and then likely 3.3, etc - 4.0 is something we're not going to be thinking about any time soon.




I didn't say it was going to be 4.0 - I went for 3.5, as 4.0 is a long way off......
Link to comment
Share on other sites


6- Adding ALL possibly available approved plugins should be as simply as doing an ADDON like in FIREFOX !




To me, compared to the forum software we are now using, it is already as simple as adding an addon for firefox.


I'm curious, besides cost, why do people want to use the IPS products without the IP.Board?
Link to comment
Share on other sites



I'm curious, besides cost, why do people want to use the IPS products without the IP.Board?




Why does every site need a forum?

Surely we should be looking at IP.Board as being one component rather than the driving force of the site.

By removing the idea that you must have a forum, opens the software up to many new clients who consider IPS to sell forums with a few add-ons.

I appreciate this is not the normal way we are used to things - but why not?
Link to comment
Share on other sites

I remember saying this when 3.0 came out that the current framework they've developed would have a very long life-cycle, longer than any of the predecessors. This is mainly down to how many strides php had taken to become a full OOP language and although things are still changing in php even php 6 doesn't implement the major changes afforded between 4>5. I think the framework will definitely get upgrades and the minimum version will increment slowly (with php 5.2 had it support ended ips might decide to move to a min version of 5.3 and take advantage of some of the new features in it, this isn't happening i said might!). The suggestion of the framework should work is very much how nexus was orginally. I think there might be room for more segmentation especially as new apps are developed by ips that use functionality from others but in the long run these will just end up being tweaks rather any big changes.

Link to comment
Share on other sites


I remember saying this when 3.0 came out that the current framework they've developed would have a very long life-cycle, longer than any of the predecessors. This is mainly down to how many strides php had taken to become a full OOP language and although things are still changing in php even php 6 doesn't implement the major changes afforded between 4>5. I think the framework will definitely get upgrades and the minimum version will increment slowly (with php 5.2 had it support ended ips might decide to move to a min version of 5.3 and take advantage of some of the new features in it, this isn't happening i said might!). The suggestion of the framework should work is very much how nexus was orginally. I think there might be room for more segmentation especially as new apps are developed by ips that use functionality from others but in the long run these will just end up being tweaks rather any big changes.




IP.Nexus v1 was too segmented ;)
Link to comment
Share on other sites



My comments were directed to the OP.



Not sure why the forums were enabled there, and I have disabled them - as you can see, the website (on IP.Content) continues to operate fine.




ah okay - you replied to my post, so just assumed ;)
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...