xoops forums

Forum Index


Board index » All Posts (AFLSC)




AFLSC

Just popping in
Posted on: 2002/1/28 0:13
AFLSC
AFLSC (Show more)
Just popping in
Posts: 10
Since: 2002/1/6 1
#1

Re: Don't Release RC2!!

The XOOPS developers have done a great job and responses to my previous postings demonstrate that they think along the same lines and are moving XOOPS away from its weblog roots forwards to something much more exciting. Perhaps RC2 is more than just a code freeze and includes some exciting new developments, but if not then this is not the time to encourage independent module developers to start coding. Because you're basically freezing the potential of XOOPS if you guarantee forwards compatibility. I'll stress it again, XOOPS is fantastic at what it does and has a great future under a very talented programming team who do that most magical of all things, listen. Just don't put the brakes on just yet.

If there are developers reading this, don't feel any pressure to reply to this thread.

Stephen

(Happy that nobody has said the obvious yet: "Do your own bloody fork!")


AFLSC

Just popping in
Posted on: 2002/1/27 21:49
AFLSC
AFLSC (Show more)
Just popping in
Posts: 10
Since: 2002/1/6 1
#2

Re: Don't Release RC2!!

Sure. I'm just suggesting that module and theme developers could await RC3 before getting permission to go to town so that XOOPS developers can consider their own design for a classification system. Throughout the forums, you can see demands for a better classification system, even if they are not phrased in that way. I don't think a little patience is too greedy, given that this product was only launched in December and it's January now. Would waiting another month really be catastrophic if it led to XOOPS being a true CMS and not a glorified weblog.

Stephen


AFLSC

Just popping in
Posted on: 2002/1/27 21:15
AFLSC
AFLSC (Show more)
Just popping in
Posts: 10
Since: 2002/1/6 1
#3

Re: Don't Release RC2!!

First I want to draw attention to your message signature: "If it ain't broke, fix it."

Secondly, I'll use this opportunity to plug one of the most impressive books I bought last year:

New Riders' WEB APPLICATION DEVELOPMENT WITH PHP4.0:
http://www.newriders.com/books/title.cfm?isbn=0735709971

Hope this is on the bookshelves of all XOOPS developers. I also found a great book the other day: it's small, it's square, it's red and it was aimed at content developers, stressing the importance of classification, but I can't think what it was called.

Stephen


AFLSC

Just popping in
Posted on: 2002/1/27 17:40
AFLSC
AFLSC (Show more)
Just popping in
Posts: 10
Since: 2002/1/6 1
#4

Re: Release RC2

If XOOPS suits your purposes, by all means use XOOPS. It's a great content management system. I'm just suggesting that XOOPS has limits which could be easily addressed without adding much visible complexity. I don't really expect RC2 to be delayed. And I don't think anybody reading this should worry that it will be.

Stephen


AFLSC

Just popping in
Posted on: 2002/1/27 15:38
AFLSC
AFLSC (Show more)
Just popping in
Posts: 10
Since: 2002/1/6 1
#5

Re: Don't Release RC2!!

XOOPS is a step forward in terms of design and pehaps ease of use, but it is still a primitive content management system. Or rather it does a great job of managing the creation of content, but a lousy job at managing that content over time. XOOPS is only six weeks old but it's already difficult to find old forum posts and news items. If you're proposed XOOPS site is something very transient (you only care about this weeks film releases, you only care about this week's football results, etc), then perhaps older content doesn't have value in your site. But personally, I get very frustrated on many of my favourite sites that the same discussions come up again and again because finding old forum posts is so difficult. It's that old Hollywood anecdote that it's easier to reshoot something at great expense than find the film cannister in the basement. I've written elsewhere why Amazon is a good content management system, but Napster is a bad one. It's very easy to find a specific book review in Amazon, whenever it was written, because it's a CMS with metadata. Yes, it's built on a database, but what is a database but a CMS.

That's why at this early stage in its development, I'm suggesting an abstraction mechanism is introduced so that there is a consistent interface for all content that allows advanced applications to be built for any content. That mechanism also builds metadata (content about content) into the system. I also suggested a possible implementation (which can be improved upon), because a content abstraction mechanism is a little more difficult to get one's head around than a database abtraction mechanism, although both serve the same purpose. In the same way that a later move from one database to another would lead to a need to rewrite all XOOPS modules, so would a late introduction of core mechanisms to manage content. An abstraction mechanism and a wrapper system for all content, ultimately simplifies the work for all module developers because complicated applications can be written by the XOOPS time for a basic content class which can be "inherited" by all modules: I'm thinking of comparative rating systems, user and group-wide annotation of content, versioning so that one can rewind changes to a calendar event, a universal bookmarking system, etc.

XOOPS already demands more from a module developer than PostNuke, for example, in demanding that you have a basic understanding of object oriented programming, etc. If you demand a little more from module developers, such as understanding how a database abstraction mechanism work, there are further advantages. I'm suggesting that XOOPS demands a little bit more from its module developers. It's an exponential thing. I agree that it's a slightly different philosophy of content and content management systems: its based on a belief that meta-content is as important as content. I don't have the time or energy to make a XOOPS fork, I'm too busy managing my own content, but it is worth my time to propose the direction that CMS are heading which will give XOOPS, our modules and the content on our individual sites a longer life. You can agree or not agree. I've had one private message from somebody who understood the article and that's enough for the article to have been worth the time I took writing it; it's served it's purpose as piece of communicative content.

Stephen

Not Scandanavian, but a huge fan of the Norwegian school of object oriented programming philosophy.

<small>[ Edited by AFLSC on 2002/1/27 15:40:14 ]</small>


AFLSC

Just popping in
Posted on: 2002/1/26 13:22
AFLSC
AFLSC (Show more)
Just popping in
Posts: 10
Since: 2002/1/6 1
#6

Don't Release RC2!!

With the forthcoming release of RC2, XOOPS developers are encouraging module developers to go to town, promising consistency with the final release. My concern is that this might be too early given that the metadata (content about content) aspect of XOOPS is still immature. I'm suggesting that at this stage a "wrapper" be introduced for all content which in addition to metadata, also builds an abstraction mechanism into content in XOOPS permitting greater code reuse and communication between modules. XOOPs is already moving in this direction, and perhaps I'll be surprised and find that RC2 has already taken steps in this direction.

Conceptually, we should be able to agree on a basic content class which all other content inherits from, adding its own attributes which specifically descibe that data. This is a design issue. We do not necessarily need to build this using classes given that PHP4 is still limited in its object-oriented qualifications. Basic attributes include a unique ID (across all content on a XOOPS site), its class ID, its creation timestamp, its author ID, a read count, the ID of the group who have permission to read it, etc. I think we can very quickly come to an agreement in what these basic attributes are.

Content also has "methods" which can operate on that data. Each piece of content knows how to display itself in various ways: sideblock, central pane, as a list member, etc. This is how I'd like to view modules. A review module is simply code that knows how to manipulate reviews. A users module is simply code that knows how to manipulate users, or rather user profiles. User profiles are content too. Perhaps a central number allocation module is also needed which ensures that all content (irrespective of its class) has a unique ID, irrespective of whether its a review, news or a user profile. There isn't a performance issue here, a module can simply ask for a block of unique ID numbers and work with them.

A list mechanism for content is also fundamental. Think of it as a bookmark list. Each user will have a collection of bookmarks: a list of users s/he frequently wishes to post messages to as a group, a list of favourite forum threads s/he is tracking, an archived list of news stories. When a user logs in it is a simple procedure to go through that users bookmarks and alter him/her when that content has changed, whether because one of his favourite authors has written a new article, a forum thread has been updated, or a calendar event they were "subscribed to" (ie bookmarked) has been cancelled. Users will want to share bookmarks, and manipulate bookmarks as a group. In fact we should probably think of bookmarks as content with a module to manipulate it.

Let's say I'm building my XOOPS site around a large database. In my case, a database of tens of thousands of films. I create a film module which wraps each piece of film content in a common XOOPS content wrapper. Additional information specific to film content such as release date, country of origin, etc, are stored in a separate database table but the common information for all site content (creation date, read count, etc) are kept in the common XOOPS content table. Yes, there are performance issues, but in database design one commonly breaks the information into separate tables. Conceptually, film content inherits from the basic content class in that it is assumed to have the same basic attributes and methods.

The next issue is metadata: content about content. When everything is content, basically we're talking about associations between content which could be implemented as a join file or by each piece of content having a bookmark list of associated content. A forum post, for example, would associate itself with various other pieces of content, all listed in the main content table, which may be a film record in a movie site, a species record in an endangered animal site, a book in a literature site, or a person in a sports site, etc. I would suggest two basic types of association across all content defined in the basic content class: primary and secondary. An advanced search could find all content (forum and news posts, etc) which are primarily about, say, Tom Cruise, without listing discussions of Mimi Rogers which mention Cruise in passing.

The issue arises here of the overhead for the user. My first get-out clause is that it is the responsibility of an editor to ensure that content is properly classified. Secondly, I suggest that content is created in a different way when you have rich classification. When I want to discuss Mr Cruise I go to the page about him where I see the list of all (primary) news stories, all (primary) forum posts and all (primary) calendar events, etc, ordered by date. When I add a forum post it is automatically associated with Mr Cruise. If I'm commenting on a post which is also associated with the Vanilla Sky content record then my post also "inherits" that primary association. I suggest an advanced Text Sanitizer also suggests other associations through a simple search of the main content table, perhaps only looking at the "title" attribute.

I'll make a list below of the attributes I'd like to see in the basic class below. I'd like to build in the concept that content can be fundamentally objective or subjective, at least in intent (for all your philosophers out there). I'd suggest that content defined as objective would need approval before posting and would be edited in Wiki-style. For simplicity, I don't include the attributes necessary for a versioning system,for rewinding changes, but that should be built into the basic content class. Same for multilingualism which I'll write about separately. And a user rating system should also be built in here, with perhaps higher rating new stories being included in the newsletter.

One important attribute across all content is a bookmark ID determing who has read access to that content. Default is everyone, perhaps represented by NULL. But this builds in a mechanism where I can annotate any content on a XOOPS site (be it a review, a news story, a calendar event or another user) which only I or my workgroup can view. One could imagine a workgroup having a private form discussion about a calendary event. "Workgroup" is a loaded word: also think about it as a "Buddy List" of friends planning a night out. Buddy Lists or Workgroups are essentially User Groups defined by the user: for administration purposes I'd suggest the user who defines the buddy group controls who can and cannot join the group. The same bookmark mechanism (since it's just a list of content IDs which may be users or any other content) could be used for a group to collect together a list of films they want to include in a book, or an individual to bookmark videotapes they own or want to buy: a longterm shopping cart.

So, what do we get here that's worth holding back RC2 (or at least an open call to module developers) for. 1) An advanced search mechanism which works across all content, whatever your site subject matter. 2) An organisational mechanism for all content by subject matter (primary and secondary association). 3) An advanced bookmarking system which works across whatever kind of content you have on your site. 4) A method of sharing content within user-defined groups. Please feel free to comment, however brutally. I'm not an experienced PHP coder but I include the attributes below as a starting point.

Wanted to post this before RC2 is released so forgive me for any inconsistencies, spelling mistakes, repetition, etc.

Stephen



APPENDIX

Basic Content Class Attibutes:

01) Unique ID

Unique for every piece of content on a site, whether it be a user profile, a calendar event, a review ... whatever. Unique because this allows any content to be associated with any other piece of content irrespective of class. This also allows bookmarks to hold mixed content.

02) Unique Class ID

I suggest here that Class ID is prefixed with the author's XOOPS.org membership number to ensure that this ID is unique across the universe of XOOPS sites. This ensures compatibility whichever modules one introduces to a site. Clearly there is an issue here when one calendar module is switched to another calendar module, but it should be simple for a site administrator to update this.

03) Author ID

Author is a User who is just content. Everything is content. I guess there is an argument to have this as a bookmark ID which lists a group of authors for collaborative content or where a number of authors have contributed over time. But I need to think more about how versioning affects this when one has Wiki-style editing

04) Parent ID

Here I'm not referring to inheritence but to the previous forum post. Since all content can be commented on, at least as personal annotation, this is built in here.

05) Child ID List

Again, this refers to follow-up posts. There is a performance issue here when it comes to annotation where hundreds of users may annotate the same news story. Perhaps annotation should be implemented with bookmarks "owned" by the user (and possibly shared with a group through the user's account).

06) Timestamp when Posted/Created

07) Timestamp when Modified

08) Primary Association ID List

The list of primary associations which is nothing more than a list of IDs. Perhaps best implemented as the ID of a Bookmark List in the central Bookmark Table. This allows for optimisation when hundreds of posts have similar associations. Again, this is an implementation issue which I'm not so concerned about in this post.

09) Objective/Subjective Status

Fundamental to content I believe. As stated above I'd suggest that "objective" content should be edited Wiki-style and need approval before being invisible to every user of a site.

10) Reader ID List

NULL means every can read this. Otherwise, it's a private piece of content for the author or a small group. Again, best to implement this as the ID of a bookmark content-type. This permits the content to be shared by a group which changes over time without updating every piece of content viewable by that group. Very often that list will have one member, indicating personal annotation.

11) Read Count

How many times a piece of content has been read

12) User Rating

I think read count is too primitive a measure of a content's worth, particularly when making qualitive decisions like whether to include a post in the newsletter. This also aids workgroups in rating the importance of a specific event, etc. Hmmm, I guess this means that the bookmark module is extended.

13) Maximum Length of Content Measured in Characters

I think it's useful to restrict the size of certain content, assuming content is as simple as a collection of characters. Even when it's not, as in a user profile, or generic database record, I think it's useful to have a description of that user or record in text. Here, or course, I'm thinking 16-bit Unicode and not being Euro-centric!

14) Language of content

Using ISO codes here. I need to think more about multilingualism along the same lines as a versioning system. Perhaps each Unique ID (1) should be extended with the language code and the version number...

15) Text

Again, I'm including it here for reasons given in (13). When this is very long as in an article, I'd suggest this should be the abstract of the article which one may like to include in newsletters and in links to the main content from other sites.

16) [Primary] Weblink Address

Again, debatable whether it should be here, but I think it should be built in for when one starts messing with SOAP, etc. This isn't necessarily (or even ideally) a link within one's own site. A forum post or a news piece will frequently be primarly around an article posted on another site. Optional.

17) Include in Next Newsletter

Determined by content type. Perhaps only modifiable by editors of the site.

18) Title

Almost forgot this. As in title of forum post, title of news story, etc. Very useful for the search mechanims and also for the Text Sanitizer to determine what other content to make associations with. But useful if alternate titles are also possible, even if not displayed here. Again multilingual system would allow other languages, but I don't want to go into that.

19) User Group List

Although not a rich enough system for classification or workgroups, it does have its very broad users. User Groups should make semantic sense. Hence a sports site has Football, Baseball User Groups, etc. Content can be restricted of only interest to a specific User Group (or several User Groups). Should be possible to display content only marked as members of the Baseball User Group, etc.

<small>[ Edited by AFLSC on 2002/1/26 13:29:43 ]</small>



TopTop