Funny that this should come up now. I was just talking about
it on IRC last
night. As a user wanting to implement links on my site, I
wanted to know
what advantage using linksDB has over CCK & views and
was pointed at the one
in CVS as well. So now I have three things to choose from
and am still not
sure. Having multiple ways to do things can be nice but also
daunting when
you are trying to figure out what to implement.
If there is an existing module for some functionality and
someone writes a
similar module, it would be lovely if they would take a few
minutes to put
in the module description what theirs does different, why
you would want to
use one of the other, stuff like that. It doesn't have to
be a fancy
comparison chart or anything, but just a quick paragraph
would do wonders to
ease the user confusion.
MichelleC
----- Original Message -----
From: "Jeff Eaton" <jeff viapositiva.net>
To: <developmentdrupal.org>
Sent: Friday, July 28, 2006 1:28 PM
Subject: RE: [development] LinksDB vs. Links
> Possibly; I would be perfectly happy to see the
incomplete
> administration screen just go away and call the module
'released'. It's
> a perfectly viable module and API package without that
one screen, and
> just as stable as image.module, say. Branching is more
of an issue.
> SysCrusher has continued to work on it, commit patches,
and participate
> in issue queues over the past several weeks so I think
it's more a
> question of calling the module 'done' and 'ready,'
which it wasn't
> before 4.7 shipped.
>
> I suppose it's just frustrating to see people look at
an existing module
> that does 95% of what's needed, and decide to
reimplement from scratch
> to get the extra 5%. There are more and more cases of
it every day, it
> seems. Sometimes it's unavoidable but often it's a
real waste.
>
> --Jeff
>
> -----Original Message-----
> From: Boris Mann [mailto:borisbryght.com]
> Sent: Friday, July 28, 2006 1:22 PM
> To: developmentdrupal.org
> Subject: Re: [development] LinksDB vs. Links
>
>
>
> On 28-Jul-06, at 9:05 AM, Jeff Eaton wrote:
>
>
> I'm not sure that's an accurate characterization.
SysCrusher hasn't had
> a chance to work on the administrative screen for bulk
link maint. work,
> but the module has been good to go under 4.7 for months
now. It has a
> robust API, very solid views integration, and is easy
to integrate with.
> The biggest problem is that 1) its description has an
outdated warning,
> and 2) it hasn't been officially branched. That latter
problem is
> definitely a big one, but I'd really suggest anyone
considering
> implementing a links management system consider
links.module and
> links.inc as their starting point.
>
> Obviously, some would prefer a smaller focused all in
one solution. 
> No problem with that. But the links package itself is
definitely not in
> disrepair.
>
>
> Would neglected be a better word? 1 & 2 as you
mention above are
> indicators to me that not enough attention is being
paid to the bundle
> (I'm not trying to diss links, just trying to find out
more about future
> direction / viability).
>
> And yes, the other big thing is the does-it-all
nature...
>
> -- Boris
>
>
>
|