How does this compare to the Web Links project?

I hesitate to call one or the other "better". I haven't used their module, but based on its documentation, it seems that they are doing a very deep implementation of what I have in links_weblink. They offer a great deal of functionality of "links as nodes", whereas the Links Package I've developed is more oriented towards "links connected to nodes".

I would invite someone from the weblinks project, or someone who uses that module extensively, to comment in more detail.

Kind regards,

Scott

Links package (this one) is more API focused. It still hasn't completed it's transition to a full Views / CCK model.

syscrusher: this isn't the right place for this, but I'd love to see this broken up into pieces. Your links functionality is very advanced, but it's not currently very "Drupal-like" -- CCK support, Views support, etc.

For example, the Link CCK field is very simplistic. I'd love to have some of the link tracking and other stuff that you can do. Your links_related is kind of pointless compared to the CCK model of adding one or more Link CCK fields to a content type. So, death to links_related :P

What you do do is some great backend API work in various places, and excellent link checking.

I'd love to seem some Darwinism applied to these various projects. The weblinks project is the easiest way to get a pure "links" directory up and running quickly. It has way too much admin and doesn't do enough Views integration (yet) but it's headed that direction.

In summary, if you need advanced link checking, a great admin interface, and a good API, use this links package.

If you want a simple links directory up and running quickly, use weblinks.

If you want to add arbitrary link fields to different content types, use the Link CCK field.

Hope that helps.

@Boris Mann:

Boris, I think your comments are well-stated, and they are IMO a fair assessment of Links Package. I am working hard to get Links to be more CCK and Views friendly, now that I have the core functionality where I want it to be. The links administration interface was a lot of work. I still don't have the link monitoring code implemented, but I have actually invented that wheel before in an unrelated project, so I know how to do that part. Also, it's not on the critical path blocking anything else in the UI side. :-)

Now that the links admin feature is working, I've already started work on CCK and Views integration. There is some Views integration for the D5 version of Links, but I need to rework it for the current D6 version of Views. You are absolutely correct that the other links-handling modules are ahead of me in this area.

My intention with the links_weblink module is mainly to provide a quick and lightweight way to get dedicated-link nodes. Over time, it will migrate toward CCK and Views, and I'll provide a graceful conversion process for existing weblink nodes. When links_weblink was initially created, neither CCK nor Views was as mature as both are today, which is why I didn't go this way from the start.

I think your statement that Links' strength is in its API is spot-on. My strength as a developer is in back-end code rather than UI development. I would welcome other contributors to help shore up the parts of Links that need improvement, so that I can focus more on the back end features.

Thanks again for your insightful comments.

Kind regards,

Scott (Syscrusher)

By the way, here is another comparison, by NancyDru. I'm working with her to get it updated to reflect the recent Links releases, but it's a pretty good overview IMO.

http://drupal.org/node/298397