Re: [Snowdrift-dev] /p/snowdrift
On Wed, May 18, 2016 at 01:09:33PM -0600, Peter Harpending wrote: > On Wed, May 18, 2016 at 11:58:54AM -0700, Bryan Richter wrote: > > On Wed, May 18, 2016 at 12:39:32PM -0600, Peter Harpending wrote: > > > On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote: > > > > I don't understand exactly why it's a corner case. Under the > > > > current system, wouldn't /p/snowdrift/ eventually be coded the > > > > exact same way as any other project, so new projects would be > > > > prevented from using `snowdrift` as a slug in the same way > > > > that they'd be prevented from taking the slug of any other > > > > existing project? > > > > > > N.B. I'm using the coqdoc convention of putting code in [square > > > braces]. > > > > > > No. As it's implemented now,[SnowdriftProject] is in its own > > > data type, defined in config/models. > > > > No it isn't. :) > > > > There is now no SnowdriftProject type, nor should there ever be. > > > > Stephen is right; this is not an issue yet. The "/p/snowdrift" > > route will go away, replaced by "/p/#ProjectSlug", and the > > snowdrift project will be the obvious owner of the ProjectSlug > > that corresponds to the route "/p/snowdrift". > > Damn, I forgot to ask this in my other email: what are you > envisioning as the type for Project. I'm thinking something like > this: > > Project > slug ProjectSlug > owner UserId > UniqueProject slug > > If that looks agreeable, can I go ahead and implement it? I want to wait to define the model based on the usage needs. I'm waiting for more information on what functionality /dashboard and /p/snowdrift will have. That needs to happen first. > How are you envisioning always creating a project named Snowdrift? > Some sort of migration hackery? Perhaps something like the old > devDB.sql? After the IRC discussion we had a while ago, I actually started to imagine that there *would* be a Project model for MVP. But, see above. signature.asc Description: Digital signature ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Re: [Snowdrift-dev] /p/snowdrift
On Wed, May 18, 2016 at 3:25 PM, Aaron Wolf wrote: On 05/18/2016 11:20 AM, Peter Harpending wrote: This is mostly directed at Bryan, but I thought it was appropriate for the entire ML to comment. I don't like using /p/snowdrift as the route to SnowdriftProjectR, because it introduces an unnecessary corner case. It means that when we eventually want to have /p/#Text, we have to use a smart newtype, and add a bunch of extra code that makes sure that nobody makes a project with "snowdrift" as its slug. Solutions: 1. Move /p/snowdrift elsewhere, like /snowdrift 2. Use /project/#Text rather than /p/#Text in the future. 3. Deal with the extra code bloat. I vote for option 1, because it's by far the cleanest. It would be really weird to have /p/snowdrift, but no /p/AnyOtherProject. If there's a special case, it should be at a top-level route, like the other special cases, e.g. /welcome, /dashboard, /search, etc. I don't like any of these solutions. My opinion as dev (being a novice) doesn't hold much weight, but I preferred the old approach of manually putting a snowdrift project in the database and not hard-coding it. I'd wonder whether a hard-coded MVP can easily change to a next version where we *remove* the hard-coding and go back to the database approach. I definitely think /project/#Text is crappy and don't want that. I *do* want the pledging to snowdrift as a project to be effectively the same as for any other project. I think what you want is the way Bryan described it. It'll be /p/#text, where #text comes from a database, which will contain a "snowdrift" entry. ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Re: [Snowdrift-dev] /p/snowdrift
On 05/18/2016 11:20 AM, Peter Harpending wrote: > This is mostly directed at Bryan, but I thought it was appropriate for the > entire ML to comment. > > I don't like using /p/snowdrift as the route to SnowdriftProjectR, because it > introduces an unnecessary corner case. It means that when we eventually want > to > have /p/#Text, we have to use a smart newtype, and add a bunch of extra code > that makes sure that nobody makes a project with "snowdrift" as its slug. > > Solutions: > > 1. Move /p/snowdrift elsewhere, like /snowdrift > 2. Use /project/#Text rather than /p/#Text in the future. > 3. Deal with the extra code bloat. > > I vote for option 1, because it's by far the cleanest. It would be really > weird > to have /p/snowdrift, but no /p/AnyOtherProject. If there's a special case, it > should be at a top-level route, like the other special cases, e.g. /welcome, > /dashboard, /search, etc. > > I don't like any of these solutions. My opinion as dev (being a novice) doesn't hold much weight, but I preferred the old approach of manually putting a snowdrift project in the database and not hard-coding it. I'd wonder whether a hard-coded MVP can easily change to a next version where we *remove* the hard-coding and go back to the database approach. I definitely think /project/#Text is crappy and don't want that. I *do* want the pledging to snowdrift as a project to be effectively the same as for any other project. signature.asc Description: OpenPGP digital signature ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Re: [Snowdrift-dev] /p/snowdrift
On Wed, May 18, 2016 at 11:58:54AM -0700, Bryan Richter wrote: > On Wed, May 18, 2016 at 12:39:32PM -0600, Peter Harpending wrote: > > On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote: > > > I don't understand exactly why it's a corner case. Under the current > > > system, > > > wouldn't /p/snowdrift/ eventually be coded the exact same way as any other > > > project, so new projects would be prevented from using `snowdrift` as a > > > slug > > > in the same way that they'd be prevented from taking the slug of any other > > > existing project? > > > > N.B. I'm using the coqdoc convention of putting code in [square braces]. > > > > No. As it's implemented now,[SnowdriftProject] is in its own data type, > > defined > > in config/models. > > No it isn't. :) > > There is now no SnowdriftProject type, nor should there ever be. > > Stephen is right; this is not an issue yet. The "/p/snowdrift" route > will go away, replaced by "/p/#ProjectSlug", and the snowdrift project > will be the obvious owner of the ProjectSlug that corresponds to the > route "/p/snowdrift". Damn, I forgot to ask this in my other email: what are you envisioning as the type for Project. I'm thinking something like this: Project slug ProjectSlug owner UserId UniqueProject slug If that looks agreeable, can I go ahead and implement it? How are you envisioning always creating a project named Snowdrift? Some sort of migration hackery? Perhaps something like the old devDB.sql? -- Peter Harpending signature.asc Description: Digital signature ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Re: [Snowdrift-dev] /p/snowdrift
On Wed, May 18, 2016 at 11:58:54AM -0700, Bryan Richter wrote: > No it isn't. :) > > There is now no SnowdriftProject type, nor should there ever be. You're right, for some reason I thought there was. I think we had some discussion in the IRC channel about how to implement the mechanism if there was a separate SnowdriftProject type, so in my head I thought there was such a type. > Stephen is right; this is not an issue yet. The "/p/snowdrift" route > will go away, replaced by "/p/#ProjectSlug", and the snowdrift project > will be the obvious owner of the ProjectSlug that corresponds to the > route "/p/snowdrift". I'm a bit concerned about this part, because this sounds like it might be a difficult change. However, we can address this later. -- Peter Harpending signature.asc Description: Digital signature ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Re: [Snowdrift-dev] /p/snowdrift
On Wed, May 18, 2016 at 12:39:32PM -0600, Peter Harpending wrote: > On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote: > > I don't understand exactly why it's a corner case. Under the current system, > > wouldn't /p/snowdrift/ eventually be coded the exact same way as any other > > project, so new projects would be prevented from using `snowdrift` as a slug > > in the same way that they'd be prevented from taking the slug of any other > > existing project? > > N.B. I'm using the coqdoc convention of putting code in [square braces]. > > No. As it's implemented now,[SnowdriftProject] is in its own data type, > defined > in config/models. No it isn't. :) There is now no SnowdriftProject type, nor should there ever be. Stephen is right; this is not an issue yet. The "/p/snowdrift" route will go away, replaced by "/p/#ProjectSlug", and the snowdrift project will be the obvious owner of the ProjectSlug that corresponds to the route "/p/snowdrift". signature.asc Description: Digital signature ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Re: [Snowdrift-dev] /p/snowdrift
On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote: > I don't understand exactly why it's a corner case. Under the current system, > wouldn't /p/snowdrift/ eventually be coded the exact same way as any other > project, so new projects would be prevented from using `snowdrift` as a slug > in the same way that they'd be prevented from taking the slug of any other > existing project? N.B. I'm using the coqdoc convention of putting code in [square braces]. No. As it's implemented now,[SnowdriftProject] is in its own data type, defined in config/models. In real terms, this means that there's a separate table in the database called [snowdrift_project]. The [snowdrift_project] table only has one row, which is inserted manually somewhere in the current source tree. [Project] will eventually be a separate data type in config/models (and therefore have its own table in the database). [Project] will have a uniqueness constraint on the slug, much like how [User] has a uniqueness constraint on the email. This uniqueness constraint is enforced at the database level. Yesod and its database library (Persistent) only take care of formatting database commands, and protecting against some security threats, such as SQL injection. The key thing here is that [Project]'s uniqueness constraint won't extend to [SnowdriftProject]. They will likely not even have the same data structure. For instance, [SnowdriftProject] doesn't need to have the concept of a "slug", because there's no dynamic routing to be done. Therefore, were we to insert any additional constraints, they would need to be either 1. Enforced at the database level, and therefore expressed through Persistent, or (maybe) a migration. This is difficult at best, and probably not possible. 2. Enforced at the Haskell level. This would mean defining a separate type, called [ProjectSlug], which would be a wrapper aroung [Text]. We'd then have to add code in the constructor of [ProjectSlug] specifying that the [Text] in the slug couldn't be equal to "snowdrift". Haskell doesn't really have the concept of a "constructor", so we'd have to use some type hackery, introducing even more performance overhead and code complexity. All of this would be avoided if we just changed the route. -- Peter Harpending signature.asc Description: Digital signature ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Re: [Snowdrift-dev] /p/snowdrift
On Wed, May 18, 2016 at 2:20 PM, Peter Harpending wrote: This is mostly directed at Bryan, but I thought it was appropriate for the entire ML to comment. I don't like using /p/snowdrift as the route to SnowdriftProjectR, because it introduces an unnecessary corner case. It means that when we eventually want to have /p/#Text, we have to use a smart newtype, and add a bunch of extra code that makes sure that nobody makes a project with "snowdrift" as its slug. Solutions: 1. Move /p/snowdrift elsewhere, like /snowdrift 2. Use /project/#Text rather than /p/#Text in the future. 3. Deal with the extra code bloat. I vote for option 1, because it's by far the cleanest. It would be really weird to have /p/snowdrift, but no /p/AnyOtherProject. If there's a special case, it should be at a top-level route, like the other special cases, e.g. /welcome, /dashboard, /search, etc. I don't understand exactly why it's a corner case. Under the current system, wouldn't /p/snowdrift/ eventually be coded the exact same way as any other project, so new projects would be prevented from using `snowdrift` as a slug in the same way that they'd be prevented from taking the slug of any other existing project? ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
[Snowdrift-dev] /p/snowdrift
This is mostly directed at Bryan, but I thought it was appropriate for the entire ML to comment. I don't like using /p/snowdrift as the route to SnowdriftProjectR, because it introduces an unnecessary corner case. It means that when we eventually want to have /p/#Text, we have to use a smart newtype, and add a bunch of extra code that makes sure that nobody makes a project with "snowdrift" as its slug. Solutions: 1. Move /p/snowdrift elsewhere, like /snowdrift 2. Use /project/#Text rather than /p/#Text in the future. 3. Deal with the extra code bloat. I vote for option 1, because it's by far the cleanest. It would be really weird to have /p/snowdrift, but no /p/AnyOtherProject. If there's a special case, it should be at a top-level route, like the other special cases, e.g. /welcome, /dashboard, /search, etc. -- Peter Harpending signature.asc Description: Digital signature ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
