HI. I'm korean. So please understand weird english.
I founded this module and tried using this module. But this module some complicate for me. And it need more improvement point.

1. How about entity based code?
Drupal 7 introduced entity. It was abstract data structure to support more flexible structure and more combinative code to drupal core. This work need a new schema structure.

2. In config page, How about change term 'Handler' to 'Protocol' or 'Protocol Handler' ?
Term 'Handler' is a riddling apeech for beginners. That means protocols handler in the code. But also that conjure up handler to store linkback data and present logic.

3. This module only redirect incoming linkback into comment.

So, I had considered make a new module. But, i think if this module improve this points, it will no more need to make new module. Especially, new schema is critical barrier to rewrite code.

Comments

manarth’s picture

manarth commented
Status: Active » Fixed

OK, I like this idea a lot…therefore, I've created a new branch 7.x-2.x, which is entity-based and refactored (it's most of the way there, could use some more tests).

I've also changed "Handler" to say "Protocol".

7.x-2.x is entity-based, and entities can be viewed in their own right - they don't need to be added as comments (there may be a valid use-case for adding them as comments, and that's a potential add-on to the module in the future, but for now having them as entites seems enough). I've created a view which shows the refbacks relating to a node.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

barami’s picture

barami commented
Status: Closed (fixed) » Postponed

Hi. I have readed a 2.x code. Vinculum has splited tables to 3 tables(Prefs, sent items, received items).
I think sent and received tables can merge into one table and they can be identified by additial flag or field (ex. status or sent/received or etc names.)

Because, two tables have overlaped fields (id, nid, timestamp, etc.). Those can be merged and handled by two bundles.

In this way, two detailed way available.

One way is to merge fields only basic infos(id, nid, timestamp, etc.). And additional infos which specified each protocols or handlers are added to seperated table by FieldAPI. Field API makes a table for each fields which can attach to entity. So It's flexible way.

Another way is to merge all fields into one table. If all fields were merged into one table, each fields can be declared the Extra field by Field API. Extra fields refered each fields on entity table and acts like regular field.

How about your think?

barami’s picture

barami commented
Issue summary: View changes

..