[23544] users/jberry/mpwa/doc/design.txt

source_changes at macosforge.org source_changes at macosforge.org
Tue Apr 3 21:22:27 PDT 2007


Revision: 23544
          http://trac.macosforge.org/projects/macports/changeset/23544
Author:   jberry at macports.org
Date:     2007-04-03 21:22:26 -0700 (Tue, 03 Apr 2007)

Log Message:
-----------
Finalize some decisions about nonemclature and urls

Modified Paths:
--------------
    users/jberry/mpwa/doc/design.txt

Modified: users/jberry/mpwa/doc/design.txt
===================================================================
--- users/jberry/mpwa/doc/design.txt	2007-04-04 02:27:31 UTC (rev 23543)
+++ users/jberry/mpwa/doc/design.txt	2007-04-04 04:22:26 UTC (rev 23544)
@@ -1,11 +1,14 @@
-This document describes in some small amount of detail the on-disk storage
-for port submissions.
+This document describes in some small amount of detail the mpwa.
 
 Goals:
 
 	- Develop a network-reachable port storage mechanism
 
 	- Allow for ad-hoc submission of new ports/revisions by any user
+	
+	- Since users may submit ports and make them available, port availability
+	  is not held up for review by committers. Committers may provide special status
+	  to approved ports.
 
 	- All submissions and versions should always remain network reachable
 	  so that old versions may be installed and/or reviewed.
@@ -25,15 +28,16 @@
 	- We begin to implement port "submit" which allows a port-directory structure
 	  to be submitted over the network through an http transaction.
 
-	- Each such "submission" is given a unique network-readable url and directory structure
+	- Each submitted port is given a unique network-readable url and directory structure
 
-	- Each submission is committed to the subversion repository.
-	  (the submission id is formed partially from the subversion revision, but that is 
+	- Each submitted port is committed to the subversion repository.
+	  (the submitted port id is formed partially from the subversion revision, but that is 
 	  an implementation detail).
 
-	- The directory created for each port submission contains the originally submitted
+	- The directory created for each submitted port contains the originally submitted
 	  compressed directory structure, an unpacked version of the same, and a meta directory
-	  that might contain other meta information (comments, build reports, build status, submitter, etc).
+	  that might contain other meta information (comments, build reports, build status,
+	  submitter inforation, etc).
 	
 Additional:
 
@@ -54,25 +58,24 @@
 	  how popular they are. Social ports.
 	
 	- Note that port submissions are final, unequivocal, and stable. Once a submission is
-	  made and assigned an id, it may not be edited. Any changes to the submission require
-	  a new submission. The same is not true for some of the metadata about a submission
-	  which may be changed (comments, build status, tags, stable, etc).
+	  made and assigned a a portid/porturl, it may not be edited. Any changes to the
+	  port require a new submission. The same is not true for some of the metadata about
+	  a submitted port which may be changed (comments, build status, tags, stable, etc).
 	
 Nomenclature:
 
-	- "submissionid": A unique id given to a submitted port.
-		Tried to stay away from port "version" or "revision", since
-		those are already used. "portid" might make sense as well.
+	- "port": A unique id given to a submitted port.
+		Tried to stay away from port "version" or "revision".
 		
 	- "porturl": a url that uniquely references a submitted port.
-		This is probably formed in part from the submissionid.
+		This is probably formed in part from the portid.
 
 Storage layout within the macports repository:
 
 	/port/submissions/catname/portname
 		/common/<unpacked directory tree> (revisioned/shared between submissions of the port)
-		/<submissionid>
-			/port.tgz (the submitted tarred-up port tree)
+		/<portid>
+			/port.tgz (the submitted tarred-up port directory tree)
 			/unpacked/<directory tree>
 			/meta/
 				/submission_info
@@ -83,12 +86,6 @@
 			
 Issues:
 
-	- Call it a submissionid or a portid? (perhaps it doesn't matter, as it's really
-	  just an internal number that becomes part of the public porturl, which is what
-	  people really use). I'm beginning to think that portid is good, as a submission
-	  of a port can be thought of as a port, and it's shorter, and doesn't suffer from
-	  bringing too much of the action into the name.
-	
 	- It is not determined yet to what degree port meta information should be stored
 	  in the database vs in the submission directory. It's likely that much such
 	  metadata (flags, tags, version, etc) should be at least shadowed into the
@@ -108,13 +105,16 @@
 		- tags
 		- flags
 		
+	- Perhaps the portid begins to supplant or replace the port revision? So that for two ports
+	  at the same version, the one with the higher portid wins, all else being equal?
+		
 	- The porturl (and our on-disk structure) currently uses/requires the category/portname
 	  subtree hierarchy. In some ways this is nice as it provides a simple human readable
 	  discriminator and allows the leaf node for each port to contain the submissionids.
 	  If we went to a flat structure for such urls (http://port.macports.org/portid) we could
 	  escape the need for category and yet still store the submissions in whatever internal
 	  form we liked. This would mean that the repository layout would no longer match the port url,
-	  which is perhaps a good thing, and it would mean that the we need some other means of
+	  which is perhaps a good thing, and it would mean that we need some other means of
 	  subsetting the internal organization of port submissions to avoid overloading the
 	  directory structure.
 	
@@ -122,7 +122,9 @@
 	  Once a submission is flagged as stable, does the previous such stable port version
 	  lose that designation? Or is it possible to determine that a port submission was previously
 	  stable? And if so, that brings up the need to be able to determine the "latest stable"
-	  submission of a port?
+	  submission of a port? Is stable, or whatever, simply a privileged tag, such that one
+	  has to have special rights to apply it, but it can be attached to as many submissions
+	  of a port as needed?
 	
 	- Though we provide a network-accessible location and unique urls for ports, we should not
 	  restrict the ability to install an http:scheme port only from this repository. The port command
@@ -135,50 +137,23 @@
 	
 Potential public urls for ports:
 
-	A simple flat/short url to access and/or uniquely identify a port submission
-			(returns the portpackage for the submission)
-		http://port.macports.org/<submissionid>
-		http://portid.macports.org/<submissionid>
-		http://submission.macports.org/<submissionid>
-		http://port.macports.org/id/<submissionid>
+			// primary access to port src packages
+			// This url returns the source package, not a human readable page
+		http://db.macports.org/srcpkg/<portid>
 		
-	URLs to port page for a port:
-			(note that the <portname>.macports.org style might preclude use of hostnames
-			like rsync, cvs, etc. Or we could use macports.com or macports.net).
-		http://<portname>.macports.org/
-		http://www.macports.org/port/<portname>
+			// A srcpkg defined by a query instead of a portid
+			// (will 301 redirect to http://db.macports.org/srcpkg/<portid>)
+		http://db.macports.org/srcpkg/latest/<portname>
+		http://db.macports.org/srcpkg/stable/<portname>
 		
-	URLs to page for a port submission:
-		http://<portname>.macports.org/<submissionid>/
-		http://www.macports.org/port/<portname>/<submissionid>/
-		http://www.macports.org/submission/<submissionid>
+			// Pages with human readable html content
+		http://db.macports.org/category/<category>	(ports by category)
+		http://db.macports.org/port/<portname>		(port by name)
+		http://db.macports.org/portid/<portid>		(port submissions by portid)
+		http://db.macports.org/tag/<tag>			(ports by tag)
 		
-	URLs to stable version of a port:
-			(redirects to the submission url for the appropriate submission of the port)
-		http://stable.macports.org/<portname>
-		http://port.macports.org/<portname>
-		http://port.macports.org/stable/<portname>
-		
-	Other urls:
-	
-		http://port.macports.org/latest/<portname>
-		
-	Favorites:
-			// Access to port packages
-		http://port.macports.org/id/<submissionid>
-		http://port.macports.org/stable/<portname> (301 redirect to submission)
-		http://port.macports.org/latest/<portname> (301 redirect to submission)
-		
-			// GUI access to port pages
-		http://www.macports.org/category/<category>
-		http://www.macports.org/port/<portname>
-		http://www.macports.org/id/<submissionid>
-		
 Issues for urls:
 
-	- do we have any portnames starting with numbers or composed entirely of numbers?
-		yes: port echo 'name:^\d'
-		note port 54321, who's name is composed entirely of numbers.
 	- If a port is installed using a url that does a 301 (permanent) redirect to another port,
 	  the url remembered as the installed port should be the redirected target, rather than
 	  the original. This would allow the url for a stable version of a port to redirect to the
@@ -193,7 +168,7 @@
 	port submit
 			==> category
 			==> portname
-			==> portpackage
+			==> src package
 			==> info
 			<== status
 			<== porturl
@@ -203,7 +178,7 @@
 			==> portname
 			<== porturls (with additional meta? flags, tags, submitter, date, version, revision, status?)
 		-- Query port submissions
-			
+	
 	port flag_stable porturl
 		-- Promote a given port submission to stable status (requires authentication)
 		
@@ -219,5 +194,5 @@
 		
 	port fetch
 			==> porturl
-			<== portpackage
+			<== srcpkg
 		-- Bring a given port into the local collection (or cache?) or ports	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-changes/attachments/20070403/4a56e3fc/attachment.html


More information about the macports-changes mailing list