Re: PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)

From: Zurab Davitiani (agt_at_mindless.com)
Date: 11/11/03 

Date: Tue, 11 Nov 2003 11:27:54 GMT

Manuel Lemos wrote on Sunday 09 November 2003 21:35:

>> That should be fine too. If you ask me, I'd be OK with simply typing an
>> ID as well. If a developer extending a class/package, they could easily
>> look up its ID without having to go through a slightly more involved
>> clipboard.
>
> Yes, I just noticed that Freshmeat also supports project dependencies
> with an interface that works that way. So, that should be fine for a
> first approach.

Good.

>> Well, if you think they are not going to do versioning, then it's not
>> worth going through the hassle, I guess. Just send out the
>> notices/requests to confirm compatibility. But, I would think, as a side
>> note, it would be great to have an optional version field for a package
>> anyway, so (for authors/packages that would use them) users know if they
>> are up-to-date or not.
>
> Yes, that is what I think is what is viable.
>
> What about the version format? Shall I let it make it arbitrary or
> enforce a format like M.m.a (Major.minor.alpha like 2.7.1)?

I don't see this as a big deal either way; but I don't think enforcing any
particular format is going to add anything meaningful. It's obvious but
just make sure you keep the date/time of each release.

>> As far as compatibility itself, you cannot do compability testing for
>> them obviously, so it's totally 100% up to the authors. But when it comes
>> down to it the question is - is your inability to confirm compatibility
>> between dependent packages a good enough reason not to offer dependency
>> linking between packages altogether?
>
> No.

Great.

>> My answer would be "no" - let the developers sort out the compatibility
>> issues - you do your part of notifying both developers (via e-mail) and
>> users (on the website) when they may occur, and let the developers, users
>> and user ratings handle the rest.
>
> Yes.

Good.

>> Yeah, that's a good idea. A simple comment field should suffice.
>> Otherwise, you would have to get involved in multiple dependency trees
>> involving combinations of factors such as:
>> - PHP major/minor versions
>> - platforms and their major/minor versions
>> - compiled in or loadable modules and their major/minor versions
>> - etc.
>
> Yes, I think I will have something like:
>
> - Required: dependency package is necessary to make dependent class work.
>
> - Base: Required package has actually a base class
>
> - Required alternative: dependency package provides a functionality that
> otherwise needs to be provided by another required alternative
>
> - Conditional: Dependency package provides functionality that is
> necessary to make the dependent package work in some conditions.
>
> - Optional: Dependency package provides a functionality that is not
> absolutely necessary in any conditions.
>
> Am I forgetting any other case?

In my opinion, the simpler the better. I would simply suggest a single
option - worded either "Required" or "Dependencies" or something similar;
If specified, the author would have to enter a comment as to the extent of
each dependency.

Otherwise, you run the risk of confusing some developers with all those
options and, thereby, ending up with incorrect data. For example, what if
some dependencies could belong to 2 different groups on different platforms
or major PHP versions? Covering all possible scenarios increases the risk
of developer as well as user confusion. UNLESS, you implement some type of
dependency tree system with multiple possible package branches. For
example, imagine package branches for PHP4, PHP5, each with different
dependency trees.

>> Well, if you plan to approve package changes manually, then that kind of
>> staging system is a good way to go.
>
> Actually a major headache to implement properly. Anyway, I think I have
> to do it soon or later because some authors tend add inappropriate
> entries. So, I would rather approve each change before it is too late.

OK.

> Either way the site still have to support individual and bulk updates.
> So, I will have something that sends out digests of file changes maybe
> hourly to avoid sending many messages to the users, which some have been
> complaining with reason.
>
> The problem of making it easy for authors to enter bulk changes in a
> single description is that some will make them vague. This is also a
> reason to have an approval stage for new or changed files.

Well, you know what my opinion is - it's up to you how you implement it. I
believe users would be well served by freshmeat-type update log - concise
and to the point. I don't think it's necessary to duplicate a CVS or a
similar individual file changelogs since the site is not a development
environment but rather a class/package repository. Well, unless you want to
take it in that direction.

> Yes, currently is too bureaucratic for large packages. What I mean is
> that if authors add a bunch of new files it will still have to be
> bureacratic because they need to enter descriptions and roles file by
> file.

See above.

> Personally, the problem that I saw with Sourceforge was not others
> forked the project but rather the attitude of some individuals of FSF
> that taken hostile measures causing eventual financial harm to VA.
>
> One thing is expressing public disagreement on the decision of VA to
> close the source of futher development and starting forks. Another thing
> is making bad PR to try to burn VA business in revenge.
>
> I think that was silly ungrateful attitude from some FSF individuals
> because Sourceforge has done a lot for the credibility and viability of
> many Open Source projects.

Well, this can happen to anyone, whether your project/service is open source
or not. There will always be differing opinions and [groups of] people who
act one way that others disaprove or do not appreciate. I guess the more
popular the project/service/website the more the likelihood of such
situations.

>> From a strictly personal point of view, I wouldn't take a Sourceforge
>> example as a means of conclusion that open sourcing a project like that
>> is automatically "bad" since someone will likely take its controls over
>> and start providing a competitive service. I mean, that's [a predictable]
>> part of it, but not all of it. Take slashcode as an example, used by 100s
>> (if not more) sites, livejournal, even Sourceforge, in this respect,
>> remains extremely popular.
>
> Sure, but VA (OSDN) and its financial muscle is too large to compare
> with me. VA can leverage the resources to keep Sourceforge alive. Maybe
> now they are paying themselves but it took a lot of money to grow that
> large. When they are that large and popular, they do not need to fear
> opening the source of the sites, unless they want to sell copies , which
> was why they decided to close the source of Open Source later.

I agree to most of your opinion, but also consider one example I stated -
LiveJournal. They actually make their users pay a fee to use their service
(in certain circumstances) while offering all their software under GPL.
Now, there are other sites that run that software, but none as popular as
LiveJournal, and none (I am guessing) with as many members and
participants. I'm not implying that all circumstances are equal, or that
you should be charging users, but the model is something worth looking at;
and maybe even having a brainstorming session over.

>> I guess what I am trying to say is that going one way or another is not a
>> simple straightforward line - it's a combination of a lot of different
>> factors; and, even in Sourceforge example, I cannot deduce that
>> sourceforge.net would have been a more popular service if it was NOT
>> open-sourced itself. I just can't draw that line.
>
> No, I think your are forgetting how it happens. Sourceforge was already
> very popular when they opened the source of the site. They really did
> not need to do that. I am sure they regret that did it. I do not want to
> regret too.

I'm not sure they regret it though. After all, wide media coverage and all
the fuss it generated did get them more attention and even more popularity.
Your situation is obviously different from VA's, so it's your judgement. 

-- 
Business Web Solutions
ActiveLink, LLC
www.active-link.com/intranet/

Relevant Pages

  • PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)
    ... Class dependency is not hard. ... you locate the dependency package and then copy it to the clipboard. ... I don't know for other developers, ... I believe in opening the source code of projects when the advantages ...
    (comp.lang.php)
  • Re: dip Notions 2 Major Errors
    ... primary arguments against the DIP are as follows: ... applying the DIP never changes the dependency so that 'y ... To the extent that the DIP inverts dependencies at the package level, ... That's a form of inversion, ...
    (comp.object)
  • Re: dip Notions 2 Major Errors
    ... B has incoming dependency from class A' becomes 'class B has outgoing ... The inversion lies in the fact that the relation in which class B ... This inversion is important in the DIP, for the DIP calls for depending on ... 'package x depends on package y' becomes 'package y depends ...
    (comp.object)
  • Re: Is there a UNIX standard for where to install local tools?
    ... First, you loose dependency tracking. ... Very old Red Hats with RPM package manager could encounter such problem. ... I realize most distributions install it. ... in the world out there more people use package managers ...
    (comp.unix.shell)
  • Re: Recommendations for PHP Form Validation Script
    ... Regardless how the authors upload ... You are right - dependency may look simple on its face, ... so that when a package is updated, ... for the filenames that are already present in the package, ...
    (comp.lang.php)