This thread contained quite a diverse range of ideas and has been quite 
difficult to summarize. This is a first attempt to summarize it, so feel 
free to chip in if you think I've overlooked something or made mistakes.

I've tried to incorporate the ideas raised into a description of how the 
collection could potentially work (a sort of specification). It's a bit 
long, so I've tried to break it up to enable you to focus in on the bits 
that most interest you.

Please comment on whether you think the following scenarios seem reasonable:

The Plan is to create a collection of  objects, textures and include files 
contributed by the POV-Ray community on povray.org.

Organisation
-------------
The site would be split into two main parts with (1) an 'ad-hoc' area for 
new submissions and (2) a 'standard' area where contributions adhere to 
certain standards and to a common licensing structure. There would be no 
visible hard-wired hierarchy of directories within these areas, but there 
would be (potentially multiple) logical categorisations available alongside 
indexing information (Keywords) supplied by the contributor. One form of 
categorisation could potentially cover topics like 'Space Hardware' and 
'Landscapes' whereas an alternative form of categorisation could cover 
contribution types, such as 'Component', 'Finished Object', 'Texture', 
'Utility Macro' etc.

The povray.org server may use an internal directory structure to manage 
versioning or other aspects of the collection, but this structure would not 
be visible to users and would not be present on the user's local machine 
once the files have been downloaded.

Submitting Contributions
------------------------
Contribution Name - To submit a contribution through the povray.org web 
site, you would first enter a name or a unique ID for your contribution.
Povray.org would search its index for that identifier.
If it's a new submission and the name is already being used, you will need 
to pick a different one.
If you intend to supersede an existing contribution you will need confirm 
that and will need to 'version' your contribution - See 'Provenance' below.

Keywords - You will need to associate keywords with the contribution so that 
people can find it through the search facility. You could be given the 
option of either submitting a file containing keywords or typing them into a 
list on the submission page, in which case the server would create the file. 
In both cases povray.org would incorporate the keywords into a machine 
readable index for use by the search facility.

Categories - You will be prompted to select one or more categories for the 
contribution. For example, a chair object could go into the Topic-based 
categories 'Household Objects' and 'Business Furnishings' and into the 
'Completed Objects' category within the Contribution-Type-based categories.

Standards Compliance - You would also indicate whether you believe your 
contribution conforms to the standards necessary to become eligible for 
promotion into the 'standard' area.

Dependencies - If the contribution has dependencies (is dependant upon 
another contribution already in the collection), you will also needs to 
identify those dependencies. As was alluded to earlier in this thread, if we 
build large lists of dependencies it becomes difficult to keep them up to 
date and to retain forward and backward compatibility as new versions of a 
contribution are added. If you write a macro that works with your objects, 
it may be safer to bundle it all together in a single contribution and 
accept that if someone wants to use it elsewhere that they'll copy it. I 
think this is one of those issues we can most appropriately handle in a 
'best-practices' tutorial once we see how this all works out.

Pre-Requisites - If your contribution has any pre-requisites you'll need to 
describe them, for example, if the contribution requires a certain version 
of POV-Ray or if there are operating system or other software dependencies 
(e.g. Use of Windows bmp format, Perl scripts, Modellers).

Description/Comments - For new contributions, you should provide a brief 
description of the contribution. If updating the contribution, you could 
optionally modify the existing description and potentially add update notes.

Server-Side Checks - The server would check that all of the file names in a 
submission are prefixed with the contribution name or some form of 
standardised prefix.
The server checks that any required files are present and accepts the 
submission, adding indexing and category information into the search 
facility and storing the files in the 'ad-hoc' area. A submission may be 
required to include a rendered image of the object at a standard size, 
documentation etc. but we'll cover that in detail in the standards thread. 
The server may perform tasks such as generating a thumbnail image from the 
submission, either from the larger image or using some sort of standard for 
rendering the contribution.

Collaborative Developments
----------------------------
Although many of the contributions could be objects contributed by a single 
author, it is also possible to foresee more collaborative developments where 
many people are updating a set of files. I think that groups working on such 
projects will need to coordinate themselves and to establish who will manage 
releases of the contribution into the collection. Such projects could 
involve development using a check-out/check-in strategy, but this would be 
managed outside of the collection using a code repository such as CVS, a 
service such as Sourceforge or some other mechanism selected by that team.

Provenance (Origin)
------------
The intention is to encourage the evolution of contributions by future 
contributors, so we need a way of accepting new versions of a contribution. 
However, we run into an issue of divergency, where two separate modification 
streams could be taking place at the same time.

I would suggest that the easiest way of dealing with this is to incorporate 
the a contributor prefix (the authors initials or tag) into the version 
number and have a place on the submissions page where the contributor can 
indicate the version that the changes are based on. If the contributor is 
registered and logged in they can use their ID in the version number. If the 
contributor is not logged in they would need to add a number each time to 
make their tag unique.

If contribution hierarchies get overly complex for a contribution then 
someone would need to sort it out. This is most likely to occur with a 
contribution where many people from the POV-Ray community have shown an 
interest, so hopefully, getting someone to put in the time to sort it out 
should be a viable option.

Finding and Downloading Contributions
----------------------------------------
The collection would be available to anyone with an Internet connection 
using a standard browser by accessing the appropriate page on the povray.org 
web site. If you have chosen to register as a POV-Ray community member you 
could have the option of logging in, which will enable the povray.org server 
to provide you with a couple of extra features (previous download lists 
etc).

Searching - You would be able to search for contributions by some 
combination of contribution name, author name, one or more category 
structures or by keyword. Multiple versions of a contribution could 
potentially be present in the collection. The most recent version would 
normally be displayed, but you could go into a 'detail' page that would list 
the version hierarchy and enable you to select an alternative version of the 
contribution.

Standards Compliance - Some means will be used to indicate whether a given 
version has been accepted into the 'standard' area. If it hasn't, the server 
could indicate whether the contributor considered that it conforms to the 
standards and has accepted the common license. Otherwise the server could 
indicate that it's an 'ad-hoc' contribution. Maybe we could use a sort of 
'traffic lights' type system.

Dependencies - An indication will be given to show dependencies on other 
contributions within the collection and an option could be provided to 
either link through to those items, or some mechanism could be provided to 
follow dependency chains and add the contribution and all of its 
dependencies to the 'download list' (see next paragraph).

Download Lists - When you find a contribution you like, you can either 
download it from the list or add it to a 'download list' similar to a 
shopping basket concept for online shops. A button on the page would enable 
you to add all items from the current selection to your 'download list'. If 
building a 'download list' you could go to your list and remove items. Once 
happy with your list you can download a zipped archive containing the files 
selected.

Value Added Features - If you register with povray.org and choose to log-in, 
the server may be smart enough to keep track of what you have previously 
downloaded so that it can indicate which contributions you already have and 
could list any contributions that have been updated since you last 
downloaded them (would require some hooks into the POV-Ray registration 
system).

Future enhancements could include downloadable indexes that could be used to 
link into platform specific user interfaces to support retrieval from the 
editor (e.g. from the 'insert' menu).

Promotion into the 'standard' area
----------------------------------
If the contributor has accepted the common licensing terms and has complied 
with the required standards, their work will be eligible for inclusion in 
the 'standard' area.

Depending upon the complexity of the standards agreed upon, it may be 
possible to automatically verify that some or all of the standards are 
satisfied. For more complex standards or for more complex contributions it 
may be necessary for a group of volunteers to go through and verify 
conformance to the required standards before registering the contributions 
for inclusion in the 'standard' area. I think we're agreed that we would 
like to keep manual maintenance tasks to a minimum.

Once a contribution has been accepted into the 'standard' area, users will 
be able to identify that fact when they come across that contribution in the 
collection (a special icon or something).

Other Stuff
-----------
There was a discussion on the subject of whether we have one file per 
object/macro or whether we support more sophisticated bundles/packages. I 
believe the conclusion was that prominent and quite stand-alone items should 
be in their own file, collections of similar features could be in a single 
file and more complex packages of files could be bundled together. Imposing 
some over restrictive rule on this could reduce the potential for the 
collection.

My view is that supporting archives of files that work together would be a 
good thing. Given the licensing conditions the exchange of  ideas could go 
both ways. Someone could take individual contributions and build them into a 
package using a standardised scale, standardised parameters and consistent 
documentation etc. Someone else could picking macros and other pieces out of 
packages and create more generic, standalone utilities out of them. I would 
foresee a smaller number of the larger packages, so it might be possible for 
those to be expanded into separate directories on the user's machine without 
hitting the 20 library path limit mentioned in the help (Charles indicated 
25, is this OS dependant?). This could maybe permit naming conventions 
within the archive to be relaxed avoiding large amounts of rework on 
existing packages.

There was a discussion about automatic renaming of contributions. I 
personally use some animation features to build the names of include files 
dynamically and I'm not sure whether we could do anything that could 
reliably update everyone's file references without risking breaking them 
beyond repair.

'Value-Added' features like "most downloaded", ratings, etc. could be added 
as time permits.
We could also implement the features described above in two phases, getting 
started with the 'ad-hoc' area and initially relying on contributors to 
assess their own contributions. We could potentially introduce the more 
formal 'standard' mark of approval at a later stage, once we can assess how 
much work/interest is generated.

Ben suggested the following categories as a starting point for a 'type' 
based categorisation:
- Textures
 o Pigments
 o Finishes
 o Normals
- Interiors
 o Media
- Shapes
 o Solid (CSG-able)
 o Non-solid (Non-CSG-able)
- Functions
 o Isosurface
 o Positioning
 o Other

I'll propose the following starting point for a 'topic' based 
categorisation:
- Household/Office Objects
- Buildings
- Landscapes
- Vehicles
- Space
- Organic Forms
- Abstract Forms


Regards,
Chris B.

Post a reply to this message

457d907f@news.povray.org...

> Ben suggested the following categories as a starting point for a 'type' 
> based categorisation:
> - Textures

(These threads are long so please ignore the following if already discussed)

IMHO it should be possible to add resource materials that are not made of 
POV-Ray SDL.

Bitmaps textures (simple or HDRI) are the more obvious case - bitmaps are 
often part of packaged scenes or objects -, but other stuff could go there 
too, including non-SDL models (think Wings or Blender models), packaged 
tutorials, BVH files, little software utilities etc. I realise that this 
opens another can of worms, but this is done in other 3D communities, and 
lots of people have non-SDL material to offer.

The fact that non-SDL goodies could be used by users of other software may 
be a good thing (more public exposure for POV-Ray and its community) or not 
(extra server load, more potential license troubles since non-SDL goodies 
are likely to have a higher commercial value than SDL ones).

G.

Post a reply to this message

"Gilles Tran" <tra### [at] inapgfr> wrote in message 
news:457da098$1@news.povray.org...

> news: 457d907f@news.povray.org...
>
>> Ben suggested the following categories as a starting point for a 'type' 
>> based categorisation:
>> - Textures
>
> (These threads are long so please ignore the following if already 
> discussed)
>
> IMHO it should be possible to add resource materials that are not made of 
> POV-Ray SDL.
>

I don't think this has been specifically discussed yet, but it's not 
necessarily a problem with the solution that has been discussed. So long as 
the files are prefixed with the appropriate contribution ID, then I don't 
see a problem with having any variety of files and file types as you need to 
make a contribution work. The application code on the server managing the 
download would create an archive incorporating the entire contribution.

> Bitmaps textures (simple or HDRI) are the more obvious case - bitmaps are 
> often part of packaged scenes or objects -, but other stuff could go there 
> too, including non-SDL models (think Wings or Blender models), packaged 
> tutorials, BVH files, little software utilities etc. I realise that this 
> opens another can of worms, but this is done in other 3D communities, and 
> lots of people have non-SDL material to offer.
>

One of the things that was discussed was also the possibility of 
incorporating more sophisticated contributions which I've suggested could 
enable the contents of the archive to evade some of the file naming 
conventions. I'm a bit biased on this as I would like to contribute a 
complex set of files which incorporates a variety of BVH files, converter 
utilities, model sources and sets of pose files, clothing files etc. and I'd 
prefer not to have to rename them all.

> The fact that non-SDL goodies could be used by users of other software may 
> be a good thing (more public exposure for POV-Ray and its community) or 
> not (extra server load, more potential license troubles since non-SDL 
> goodies are likely to have a higher commercial value than SDL ones).
>
> G.
>

Regards,
Chris B.

Post a reply to this message

Two quick issues to pick apart. I just got done with exams so I haven't
had enough time to go through everything yet.

Chris B wrote:
> Organisation
> -------------
> The site would be split into two main parts with (1) an 'ad-hoc' area for 
> new submissions and (2) a 'standard' area where contributions adhere to 
> certain standards and to a common licensing structure. There would be no 
> visible hard-wired hierarchy of directories within these areas, but there 
> would be (potentially multiple) logical categorisations available alongside 
> indexing information (Keywords) supplied by the contributor. One form of 
> categorisation could potentially cover topics like 'Space Hardware' and 
> 'Landscapes' whereas an alternative form of categorisation could cover 
> contribution types, such as 'Component', 'Finished Object', 'Texture', 
> 'Utility Macro' etc.
> 
> The povray.org server may use an internal directory structure to manage 
> versioning or other aspects of the collection, but this structure would not 
> be visible to users and would not be present on the user's local machine 
> once the files have been downloaded.
> 

Even the ad-hoc should have to be under a compatible license. If it is
not licensed for redistribution, then someone could complain that the
server was giving it away with permission. That may sound strange, but
it would be safer if we knew we had permission to redistribute the
files. Secondly, it allows others to patch a file to make it standards
compliant.

If we want to allow non-similar licensed files in the library, then the
traffic light indicator you mentioned could be useful. Stop for
privately licensed, read the files carefully. Slow/caution for standard
license but not prefixed or checked, and go for checked over and should
work with the current version of POV-Ray.

> Submitting Contributions
> ------------------------
> Contribution Name - To submit a contribution through the povray.org web 
> site, you would first enter a name or a unique ID for your contribution.
> Povray.org would search its index for that identifier.
> If it's a new submission and the name is already being used, you will need 
> to pick a different one.
> If you intend to supersede an existing contribution you will need confirm 
> that and will need to 'version' your contribution - See 'Provenance' below.
> 

Just for everyone to think about, who's name should go on a file that
was patched? If I fix a bug, or typo or what ever, in someone elses
library, the most I'm going to do is add a comment saying I fixed
something and why, and add one to the patch version level. If the server
is appending a prefix based on the uploader's name, then we could end up
with two files doing the exact same thing.

The solutions I could come up with follow:
1)Server allows uploading over established files. I could see this being
really bad, but it would solve this single issue.
2)Allow only the contributor to over write their file, and make sure
that all patches are sent to them. This could pose a problem if the
contributor doesn't want to update or just can't be found.
3)Only designated people can overwrite files. There could be many ways
of determining this. Only head folks in the Library Team, a specific
patch manager, everyone with a patch that has been downloaded 100 times.

Post a reply to this message

457dc4d2$1@news.povray.org...

> I don't think this has been specifically discussed yet, but it's not 
> necessarily a problem with the solution that has been discussed.

Thanks for the answer. I just wanted to make sure that the option was 
mentioned somewhere. Note that the license should also cover these kinds of 
materials (not just SDL).

G.

Post a reply to this message

"Sabrina Kilian" <ykg### [at] vtedu> wrote in message 
news:457dd079@news.povray.org...
> Two quick issues to pick apart. I just got done with exams so I haven't
> had enough time to go through everything yet.
>
> Chris B wrote:
>> Organisation
>> -------------
>> The site would be split into two main parts with (1) an 'ad-hoc' area for
>> new submissions and (2) a 'standard' area where contributions adhere to
>> certain standards and to a common licensing structure.
>
> Even the ad-hoc should have to be under a compatible license. If it is
> not licensed for redistribution, then someone could complain that the
> server was giving it away with permission. That may sound strange, but
> it would be safer if we knew we had permission to redistribute the
> files. Secondly, it allows others to patch a file to make it standards
> compliant.
>

I think I missed a bit out in my summary. I think the idea proposed by Chris 
Cason was that the contributor would still need a fairly liberal license, 
but they may elect to require 'Attribution', so his suggestion was that they 
would be required to include something like the following trap in their SDL 
to prevent people from using their contribution unwittingly.

 #ifndef (Attributed_Includes_OK)
    #error "This include file requires attribution"
  #end

I'm fairly impartial on this because I can see that it might help encourage 
more contributions, but I think it does add a layer of complexity and I'm 
pretty confident that a lot of people will be happy to contribute without 
requiring attribution, just as a sort of give-back gesture.

>> Submitting Contributions
>> ------------------------
>> If you intend to supersede an existing contribution you will need confirm
>> that and will need to 'version' your contribution - See 'Provenance' 
>> below.
>
> Just for everyone to think about, who's name should go on a file that
> was patched? If I fix a bug, or typo or what ever, in someone elses
> library, the most I'm going to do is add a comment saying I fixed
> something and why, and add one to the patch version level. If the server
> is appending a prefix based on the uploader's name, then we could end up
> with two files doing the exact same thing.
>

I would suggest that we don't routinely delete any version although there 
may be special circumstances where an administrator would go in and make 
deletions (e.g. if one or more contributions is intentionally corrupted or 
if older versions are not downloaded for a year or so and no other 
contributions depend on them).

I see the versioning as being largely internal to the server, so that you 
only get one entry for a contribution coming up on a search, but when you 
look at the entry you can see that multiple versions have existed and can 
select the one you want. Normally you'd go for the latest. I think the files 
you download would not be prefixed with a version number or contributor ID, 
because this would interfere with anything you've written to use them. There 
could be an auto-generated 'version' file containing the version number in 
the name - e.g. 'TennisBall_SK_V2.3.ver' that contains information about the 
provenance of this version.

If you fix a bug, you would upload a new version of the whole contribution 
having tested it as a complete unit. You wouldn't change the name of the 
original author as registered on the server if it's just a little fix, but 
would merely add a comment to say what you'd done. This contribution would 
have your initials or tag against it in the versioning information and 
people would be able to select either your newer version or the original 
version if they prefer. Dependencies in other contributions may still need 
to point to the older version of this contribution.

If the original author subsequently applies the same fix to the same bug, 
then yes, you end up with two virtually identical files on the server, but 
hopefully the comments will cast some light on that.

Regards,
Chris B.

Post a reply to this message

It all looks good so far, of course I only gave it a quick read :)

There are two things I'd like to further suggest, however:

1) All contributions should be required to submit to a particular 
(non-exclusive) license, similar to what the IRTC does.  Ie, "I agree to 
the standard license, and allow anyone with access to this repository to 
use my contribution for any purpose whatsoever, including making changes 
and submitting patches to the repository."  Or something like that.  The 
point is, if I access something from the repository, I don't want to 
have to read over the license for it to determine whether or not I 
should use it.

2) In the vein of "value-added features", I'd recommend allowing users 
to rate the individual files according to several criteria, such as 
Completeness, Usability, Realism, Uniqueness, etc (those are just 
examples), as well as add comments / reviews about them.  If a 
submission has multiple versions, allow the viewing of aggregate reviews 
(for all versions combined), or for a single version.

...Chambers

Post a reply to this message

First, thanks for all your thought & effort Chris.  Supposing this thing
gets off the ground it'll be in no small part thanks your efforts in
getting everybody together in discussing it.

"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> foresee a smaller number of the larger packages, so it might be possible for
> those to be expanded into separate directories on the user's machine without
> hitting the 20 library path limit mentioned in the help (Charles indicated
> 25, is this OS dependant?). This could maybe permit naming conventions

If I'm not mistaken I'm reading this as a standard limit for all platforms:

http://www.povray.org/documentation/view/3.6.1/56/

Where did you find 20?

Charles

Post a reply to this message

"Charles C" <nomail@nomail> wrote in message 
news:web.457e46ca6bf4081b9926319c0@news.povray.org...
> First, thanks for all your thought & effort Chris.  Supposing this thing
> gets off the ground it'll be in no small part thanks your efforts in
> getting everybody together in discussing it.
>
> "Chris B" <c_b### [at] btconnectcomnospam> wrote:
>> foresee a smaller number of the larger packages, so it might be possible 
>> for
>> those to be expanded into separate directories on the user's machine 
>> without
>> hitting the 20 library path limit mentioned in the help (Charles 
>> indicated
>> 25, is this OS dependant?). This could maybe permit naming conventions
>
> If I'm not mistaken I'm reading this as a standard limit for all 
> platforms:
>
> http://www.povray.org/documentation/view/3.6.1/56/
>
> Where did you find 20?
>
> Charles
>

Hmm. I see.
I was looking at 2.1.2.5.4 Library Paths where it says "Up to twenty unique 
paths may be specified".
http://www.povray.org/documentation/view/3.6.1/220/

Regards,
Chris B.

Post a reply to this message

"Ben Chambers" <ben### [at] pacificwebguycom> wrote in message 
news:457e3915$1@news.povray.org...
> It all looks good so far, of course I only gave it a quick read :)
>
> There are two things I'd like to further suggest, however:
>
> 1) All contributions should be required to submit to a particular 
> (non-exclusive) license, similar to what the IRTC does.  Ie, "I agree to 
> the standard license, and allow anyone with access to this repository to 
> use my contribution for any purpose whatsoever, including making changes 
> and submitting patches to the repository."  Or something like that.  The 
> point is, if I access something from the repository, I don't want to have 
> to read over the license for it to determine whether or not I should use 
> it.
>

Sabrina made the same point. I can see both sides. One aspect of it that I 
don't think was yet discussed is that if someone creates something based on 
another Open Source license, then they may not be able to comply with our 
license terms without breaking the terms of that other license. I guess the 
answer is that they can still publish on their own web site and add a link 
into the povray links collection or promote it on these newsgroups.

Two ways forward on this question spring to mind. We could have a vote on it 
or we could start by requiring a common license and ease up if it seems to 
be causing a problem.

> 2) In the vein of "value-added features", I'd recommend allowing users to 
> rate the individual files according to several criteria, such as 
> Completeness, Usability, Realism, Uniqueness, etc (those are just 
> examples), as well as add comments / reviews about them.  If a submission 
> has multiple versions, allow the viewing of aggregate reviews (for all 
> versions combined), or for a single version.
>
> ...Chambers

I like this idea.

Regards,
Chris B.

Post a reply to this message