While comments currently are expandable it's not a good thing really -- those decorated comments should be nodes, we currently have a hook comment which is almost as rich as nodeapi just not quite and having two almost same but not really same ways to do things are quite ugly. This is already recognized by other comments-as-nodes movements. Normal comments and aggregator items should be small nonfieldable nonexpandable fast pieces that have an author (which can be anonymous), subject, body, link. Still comment and aggregator item would be a different table with additional columns like GUID or thread but these do not change the matter that a whole page of items can be retrieved with one single query and thrown out rather quick. If you really want to add more displayable things then hook_schema_alter, hook_query_alter and custom theming is your friend.
Comments
Comment #1
chx CreditAttribution: chx commentedOn second thought, after a discussion with Moshe *maybe* we keep comment API but still, using the same small and quick API for aggregator items and comments makes some sense to me.
Comment #2
catchWith the current state of hook_comment_load() - having modules enabled which implement the hook is likely to slow things down to node levels, since there's no multiple load for comments (and I don't plan to write one). Also having comment_upload() and all these other modules which have to reinvent the wheel is evil. Making them fieldable would introduce the same issues.
At the same time, when benchmarking raw nodes vs. raw comments, especially at high numbers per page, - comments beat nodes in a big way at the moment with anything over 10-20 per page. So blog sites which need a very lightweight solution and won't be trying to do anything else would get an unacceptable penalty, unless we can radically speed up nodes in the meanwhile.
So, stripping comments down to an extremely lightweight item (and aggregator items are a good fit for this model too) makes a lot of sense to me, and chx suggested allowing for comments-as-nodes in core as an option, to 1. provide an upgrade path for those using hook_comment() modules 2. save making comments themselves heavier to accommodate these use cases.
Comment #3
MichelleHere's a discussion we were having on g.d.o about micronodes last month that may be relevant: http://groups.drupal.org/node/17847#comment-61153
Michelle
Comment #4
SeanBannister CreditAttribution: SeanBannister commentedMichelle: are you working on Drupal 7 forums? I heard there was talk of forum comments as nodes?
There's definitely a need for adding CCK fields to comments but I don't think this should penalize those who don't need this functionality. I would support a comments as nodes option in core so users have the ability to turn this feature on if needed.
Comment #5
Michelle@SeanBannister: It depends on when freeze is. I'm too swamped in contrib to think about core, yet. Once I get 1.0s out of all my modules, I'll have more breathing room. At any rate, our plan was not to make all comments nodes but to specifically make all forum posts nodes. It wouldn't be optional as core forum would be rewritten to use all nodes.
Michelle
Comment #6
chx CreditAttribution: chx commentedAbout comment links, I think comment module will provide a basic set of comment links in an array and let preprocess change that if at all necessary. We still can cache the whole rendered chunk per role.
Comment #7
catchComment links proposal sounds good to me.
Comment #8
alex_b CreditAttribution: alex_b commentedI like this idea. I'm still wrapping my head around what this could mean for aggregator. I'd like to see more specifically what this API would consist of: basic approach + API functions.
Comment #9
alex_b CreditAttribution: alex_b commentedHow does this look for a start?
// Create storage for the items that we'd like to store.
drupal_item_create_table('aggregator_item', $schema);
// Insert/update a new item.
drupal_item_save('aggregator_item', $item);
// Delete an item.
drupal_item_delete('aggregator_item', $item);
// Load one or more items.
$items = drupal_item_load('aggregator_item', $ids);
// Destroy item table.
drupal_item_drop_table('aggregator_item');
Every item is going to have at least a column id as primary key. In drupal_item_save() there could be a drupal_alter() before the $item goes to the DB. Otherwise existing schema and query hooks should be sufficient to extend the item API. drupal_item_create_table() would create the database table, store the schema and expose it through hook_schema().
We could use this for comments and for aggregator items - what else?
Comment #10
tstoecklerI know this is far from being committed, but with this: #119102: Combo field - group different fields into one, comments could be A FIELD (vs. fieldable). The same could go for aggregator items. Just wanted to crossreference...
Comment #11
catchnedjo also has some work on generic load for objects in #365899: API methods for schema-based load and delete operations.
Comment #12
chx CreditAttribution: chx commentedGood people, what the mythical data API has to do with this? We are loading a bunch of items belonging to an entity, paged. I have no intentions of providing a CRUD API, use drupal_write_record, period. Small, simple etc.
Comment #13
XanoComments are now entities.