I agree that tagging is a better solution than (always arbitrary)
hierarchies. Over time, I have learned that any hierarchy is always
wrong for some people. Flickr shows how people can create their own
groups by including a set of tags and I think it is highly successful.
Or look at SQL, invented to solve the problem of hierarchical (or
networked) databases that always turned out to have the wrong
hierarchy for any new application.
You can always create groups by searching for tags or create tracks
like they use on EclipseCon to create mini-programs.
In the OSGi, we have the Bundle-Category header that has a set of
defined values. We gladly adjust this list.
http://www2.osgi.org/Specifications/Reference
Kind regards,
Peter Kriensa
AvD I was primarily thinking about web pages for downloading and searching
AvD bundles. A download page which would show all server side bundles would
AvD have some items that are also on the standard bundles page. It doesn't
AvD solve the problem of what each downloadable item should comprise and it
AvD doesn't help with tools like bugzilla or how to address things on the
AvD mailing lists. Personally I would tend to make the items small when
AvD tagging is available, e.g. a download per bundle. I'd do the same on the
AvD bugzilla side with rather fine grained partitioning.
AvD The download pages could even offer you to choose several
AvD tags/categories to include in your download and then pack you an
AvD individual downloadable bundles archive without duplicates and all the
AvD items you wanted. (Ah, the lovely smell of over-engineering in the early
AvD morning :) ).
AvD Arthur
AvD Jeff McAffer wrote:
can you say more about the mechanism for tagging? The sorts of
media/item in question are downloads, bundles in the repo, wiki/web
information, posts on the mail list or newsgroup, bugs, ... Not all
need the same level of rigor perhaps.
Jeff
*Arthur van Dorp [EMAIL PROTECTED]*
Sent by: [EMAIL PROTECTED]
09/14/2007 01:20 AM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org
To
Equinox development mailing list equinox-dev@eclipse.org
cc
Subject
AW: [equinox-dev] Equinox-Bundles component is getting crowded
The challenge is that all
partitionings will have problems as different people have different
views on the world. would the http service be part of standard
services or server side?
As an outsider I'd say use tags. HttpService would be tagged
AvD standard
as well as server side. That would naturally involve some work on
AvD both
front and back end and not in itself guarantee that people would
AvD easily
find what they are looking for.
Arthur
Jeff McAffer wrote:
to me it is neither of these options. It is about community and
clarity
for our consumers. Walking up to Equinox you just have a sea of
bundles. Add in the p2 and security stuff and the sea turns into
AvD an
ocean. Say you hear that Equinox has implementations of some OSGi
service specs. If you go to the download page today you have to
grovel
through spec impls, launchers, random other stuff and cannot tell
AvD one
from the other. Since there is no particular web/wiki page for
AvD people
interested in spec implementations, it is hard to build a community
around that topic. People interested in contributing to standard
spec
impls cannot easily find related bugs etc. There is also no clear
lead
of that community who is plotting the course/planning, coordinating
execution, building the community, ... You can replace OSGi
AvD service
spec with p2, security, ...
A number of these issues can be addressed simply by structuring the
download site or wiki or... If you address most of them then in
effect
you have just created a component without actually creating a
component.
So what are we afraid of? Why not reify the structure we think we
have?
That begs the question, what is the structure? The challenge is
AvD that
all
partitionings will have problems as different people have different
views on the world. would the http service be part of standard
services or server side? However the existance of issues need
AvD not
stop progress or movement. So this discussion is really about
defining
that structure. At least thats my view...
Jeff
*BJ Hargrave [EMAIL PROTECTED]*
Sent by: [EMAIL PROTECTED]
09/12/2007 05:13 PM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org
To
Equinox development mailing list
equinox-dev@eclipse.org
cc
Subject
Re: [equinox-dev] Equinox-Bundles component is
getting crowded
What is the point of the proposed change? Tom's mail suggests we
subdivide
