I agree eafarris about having the core of freelinking free of DB http://drupal.org/node/621180#comment-2219226
which might help improving its development cycle

nevertheless, a major issue seems to require it #465360: freelinks don't redirect properly when content is cached

so, I'm proposing to bundle the release of FL3 with an optional sub-module capable of bringing DB support (kind of basic freelinks tracking) to sort out the most sensible issues

after that, other complementary modules might provide better approaches replacing optional FL3DB provided

Comments

Grayside’s picture

Grayside commented
Status: Active » Postponed

This sub-module would be a prime consumer of #621180: Unique Links by Page.

I agree that this should exist. I am on the fence as to whether it should be an FL-specific module, or a grander module that looks at all links and has special integration for Freelinking. I've decided the first step in either case is a Freelinking submodule, as this functionality will be a lot easier as part of Freelinking than something using hook_cron to crawl the site in search of HTML links.

I think this is more likely something that will be targeted more at FL3 1.1, rather than the initial release. (Unless you would like to tackle it?)

Reaction Thoughts

  • I prefer a more human-intuitive name, such as Freelinking Tracker.
  • The main functionality should include CRUD functionality and an ability to produce nice lists of Freelinking-generated links. I suspect Views integration (via Table Wizard or simply a Field handler?) might be a way to go on enabling advanced lists by user, content type, etc.
  • The module should be easily added-to, probably via drop-in plugins and modules similar to how Freelinking plugins work. One such drop-in plugin should be the mechanism to clear the cache. This functionality allows folks to more easily submit code or create modules to do oddball things like integrate Freelinking with one of the Charts APIs. We should not expect someone else to create a FLDB module, but merely to want the use of one.

Possible Items for DB Schema

  • flid
  • The unrendered link array, serialized.
  • Plugin name that generated the link.
  • The serialized failover trace, showing the history of the link's generation.
  • Source Path of Text
  • Destination domain
arhak’s picture

arhak commented

@Grayside
I have my own draft halted due to lack of time to spare on it

whenever I'm posting in a Drupal site I think about having freelinks/wiki-links, but certainly most people can live without it, refraining them self from referencing other relevant resources or by simply naming titles without dropping the appropriate links
they aren't in favor of spending development time to get this done :(
so other tasks gets prioritized

arhak’s picture

arhak commented

BTW: if you intend to have a DB-driven sub-mod which solves most of problems then the schema will need more analysis, it seems to me that your first draft is missing something (that's why I'm with eafarris about not having DB in FL3 core)

as this gets (wisely) postponed, we should get back here to discuss schema more deeply before getting it done

arhak’s picture

arhak commented

@http://drupal.org/node/613236#comment-2288162

I have been wondering whether Freelinking DB should be a separate project or a sub-module

a separated project IMO

a DB-driven module will require upgrade path whenever schema be changed

having it as a sub-mod will make it the deployment blocker, the same as having DB back end in the core API of FL3

Grayside’s picture

Grayside commented

Part of "separate project" is the question of whether it's long-term evolution is Freelinking-specific or just Freelinking-centric.

Grayside’s picture

Grayside commented
Title: FL3 should be released with an FL3DB sub-module » FL3 DB Functionality Through Separate Project

If this is Freelinking-centric, all FL3 database stuff should probably be in the same place. #634332: Freelinking UI can join the party as another DB-driven Freelinking tool.

arhak’s picture

arhak commented

@#6 -1, I disagree

UI might require a wide different schema, and absolutely unrelated with the DB-driven part of freelinking
those might be even maintained by different staff

AlanAtLarge’s picture

AlanAtLarge commented

subscribing

juampynr’s picture

juampynr commented
Status: Postponed » Postponed (maintainer needs more info)

This has been left forgotten. Does the fact that some freelinks may get broken with the time really needs such an amount of work?

I think I still do not get the big picture, am I missing something?

juampynr’s picture

juampynr commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

Closing. No further feedback was given.