PoshCode Wiki & Documentation Rss Feed

Updated Wiki: WebUI

Jaykul — Fri, 20 Mar 2009 16:38:42 GMT

We really should probably start putting together a UI Spec ...

In proper MVC fashion, there's no reason we have to wait until the rest of the logic is done ...

<RichardP> ok, i can do basic html mockups fairly quickly - week or two? See if you like them and then convert to mvc ...
<Jaykul> Yeah, that would be great

Borrow heavily from Digg, zembly, php.net ...

For the record: We wan't a light design. Not black on white necessarily, but navy or green on light yellow or beige...

The front page will be a list of scripts. Search results, user profiles, and navigation (categories, and tags) will be lists. There will also be a page template for the items, and of course the user profile will have profile data on it, before the list of scripts by that user.

Navigation-wise: there will be a category tree (possibly stolen from Microsoft's scriptcenter), and there will be free-form tags (and logged in users will be able to tag everything: people, scripts, whatever).

Whenever we have lists, they must be abbreviated compared to the current front page/search list (less content for each item, more items)
We must have a conspicuous "contribute" button EVERYWHERE
On the item pages, there will be a comments section for each submission (do we want these per-version? If not, we should do newest on top)

I believe we want to have two types of "reuse": EDIT and COPY FROM. The idea being that in the first case you're creating a new version of the base script, but in the second you're creating a new script which borrows from the first script. Perhaps what I really mean is that "edit" should copy over the content from the base script, whereas "copy from" should just be something where you can fill in a field with a list of "related contributions." What do you think?

There must be a button on every script contribution to "edit" it (ie: create a new contribution based on it)

There will be levels of contributions (I have a list in the spreadsheet on http://docs.poshcode.org) but from memory: snippet, function, script, module, and BINARY module.

There will be multiple code languages present

At least PowerShell and .net langs: C#, VB, Python, Ruby, PLUS: VBScript and Perl are mandatory. However, there's no need to highlight the multi-language features, they'll be filterable in the search feature, of course.

16:26:14 <Jaykul> yep
16:26:24 *Jaykul is logging this to put on the wiki
16:26:28 <RichardP> Jaykul: php documentation engine - steal heavily from it, its fucking awesome
16:27:09 <RichardP> and looks to be a large part of what you want - sure, theres lots of stuff you want on top, but its quite a way there. steal from it :)
16:27:30 *Jaykul nods
16:27:35 <Jaykul> so, on the front page (and on search results), each item will have:
16:27:42 <RichardP> and the layout is good as well
16:27:54 <Jaykul> * RANK (there will be user-voting, but not from the list pages)
16:28:13 <Jaykul> * Submitter (or "anonymous")
16:28:17 <Jaykul> * Title
16:28:27 <Jaykul> * The first line of the "Description"
16:29:06 <Jaykul> * Language (maybe an "icon" in the right-corner of the "box" for each submission?)
16:29:28 <RichardP> what icon could symbolise a language?
16:29:36 <RichardP> oh
16:29:38 <RichardP> heh
16:29:44 <palen> Powershell has the >_
16:29:45 <Jaykul> Well, like ">_" or "C#"
16:29:47 <RichardP> yeah, lancuage :)
16:29:56 <Jaykul> or "VB" or whatever
16:29:56 <palen> Ruby could be a ....ruby
16:30:03 <RichardP> I was thinking 'cant do country flags cos China has like a billion langauges'
16:30:20 <palen> Haha
16:30:23 <Jaykul> hehe
16:31:11 <Jaykul> * Links: 1) to the full details page, 2) direct to the download, 3) to the user profile of the submitter
16:31:36 <RichardP> Jaykul: how about an 'add to download package' feature as well?
16:31:39 <Jaykul> * Tags: at least the first 3 or so
16:31:55 <Jaykul> RichardP: uhm... how about for v2.2
16:31:56 <Jaykul> ;)
16:32:01 <RichardP> heh
16:32:26 <Jaykul> I have a hard deadline in May for this to be up
16:32:28 <Jaykul> ;)
16:32:41 <RichardP> hahahah
16:32:44 <RichardP> :D
16:32:51 *Jaykul sighs
16:32:54 <RichardP> why the hard deadline?
16:33:03 <palen> TechEd?
16:33:05 <Jaykul> Uhm...
16:33:11 *Jaykul whistles idle
16:33:16 <RichardP> heh
16:33:16 <palen> :o
16:33:22 <RichardP> oh yes
16:33:25 <RichardP> i do recall
16:33:34 <Jaykul> Lets just say ... there might be something big later in the summer
16:33:53 *** ghostz has left the room ("http://www.mibbit.com ajax IRC Client" (i=aab90e64@gateway/web/ajax/mibbit.com/x-44b5adf02bee9266))
16:33:56 <Jaykul> I should know for sure later this week
16:34:07 <RichardP> Jaykul: Im away this weekend, but I have all of next week and weekend to put some serious work in
16:34:08 <palen> I bet it has something to do with that interchange between Jaykul and hal about 'that thing only you and I know about'
16:34:23 <RichardP> palen: oh, other people know :)
16:35:38 <Jaykul> Yeah, there was a conf call earlier ...
16:36:05 *Jaykul trails off
16:36:15 <palen> Ominious
16:36:17 <Jaykul> and I don't want to talk about it for fear of jinxing it
16:36:20 <palen> And ominous
16:36:32 <palen> Fair enough
16:36:40 <Jaykul> but in any case, it involves getting this up sooner rather than later.
16:36:50 <RichardP> Jaykul: just one requestion - please please please dont make me do a tag cloud , they are only self propagating
16:37:04 <RichardP> oooh, new word - requestion :D
16:37:24 <Jaykul> self-propagating?
16:38:23 <RichardP> Jaykul: click on one, it gets bigger because its used, which means people are more likely to click on it, which means its more popular, which means it gets bigger, which means...
16:38:31 <Jaykul> oic
16:39:11 <Jaykul> We will have tagging, but I don't see any value in showing how often a tag gets used, or which tags are more popular
16:39:57 <RichardP> i have no issue with tagging, or even showing in a list whats more popular, but tag clouds are horrible things
16:40:05 <Jaykul> hehe
16:40:21 <Jaykul> Fine with me :)
16:40:42 <Jaykul> OK, so ... I think that mostly covers the ... "list" pages
16:41:18 <Jaykul> the actual details pages are going to need to show ... all the data in that Dublin Core document
16:41:20 <palen> Wow
16:41:22 <Jaykul> plus the script
16:41:30 <palen> Some people have no filter on their bug reports...
16:41:34 <Jaykul> (or scripts, at some point)
16:41:36 *** pantocrator has joined the room as a participant and a member
16:42:05 <pantocrator> hi
16:43:25 <Jaykul> hi
16:44:48 <Jaykul> RichardP: Two interesting UI-type things I want to try: 1) "derivative scripts" (ala github: show how many people have posted new versions of, or new contributions based on "this" contribution (this is important for May)) 2) a "edit history" timeline ... as a way to show the "previous versions" of a script.
16:45:23 <palen> Oo, oo, could we hook them up to NodeXL?
16:45:26 <RichardP> Jaykul: 3) 'where has this code been used elsewhere?'
16:45:34 <Jaykul> For the timeline thing we might be able to borrow from the chandler project thing
16:45:46 <Jaykul> Or make something in Silverlight
16:45:53 <Jaykul> for either, or both
16:46:01 <Jaykul> palen: Hmmm!
16:47:48 <palen> And a ZUI
16:47:57 <Jaykul> deepzoom
16:48:15 <Jaykul> ooh, timelines for users ...
16:48:27 <Jaykul> that would be cool
16:48:34 <Jaykul> we will want profile pages for users
16:48:52 <Jaykul> and a "diff" page
16:49:04 <palen> Profiles optionally linked to twitter?
16:49:17 <RichardP> oh god, please dont include any social networking stuff ;)
16:49:25 <Jaykul> profiles will include twitter ids
16:49:26 <palen> Haha
16:49:32 <Jaykul> but I dono about anything else
16:49:33 <palen> Ha, I win!
16:49:46 *RichardP sharpens his stabby thing
16:49:46 <Jaykul> the PoshCode bot already posts on twitter
16:49:53 <Jaykul> whenever someone contributes
16:50:08 <Jaykul> Twitter is the new, suckier, RSS

Updated Wiki: WebUI

Jaykul — Mon, 16 Mar 2009 20:52:13 GMT

16:12:43 <Jaykul> Actually, you really could probably start putting together a UI in proper MVC fashion ...
16:12:46 <RichardP> ok, i can do basic html mockups fairly quickly - week or two?
16:13:04 <RichardP> see if you like them and then do the mvc step
16:13:16 <Jaykul> I mean, we know what data we will have, and what we will need feature-wise on the UI
16:13:22 *Jaykul nods
16:13:28 <Jaykul> Yeah, that would be great
16:14:00 <RichardP> do you have a featurelist for the UI?
16:14:36 <Jaykul> That's a good question.
16:15:53 <Jaykul> I think I'm going to say: not really.
16:16:20 <RichardP> heh
16:16:30 <RichardP> got any ideas of what you actually want?
16:17:15 <Jaykul> I just checked, and although there's a section labelled "User Interface" in my requirements page on the wiki, it's basically empty.
16:17:19 <Jaykul> so
16:17:52 <Jaykul> 1) the list of scripts must be abbreviated, compared to the current list
16:18:07 <Jaykul> (less content for each item, more items)
16:18:53 <Jaykul> 2) We must have a conspicuous "contribute" button EVERYWHERE
16:20:03 <RichardP> Jaykul: heh
16:20:06 <RichardP> Jaykul: categories?
16:20:10 <Jaykul> 3) Everyone wants a lighter design ala Digg/zembly: not black on white, but navy or green on light yellow or beige
16:20:12 <RichardP> Jaykul: languages?
16:20:18 <Jaykul> structure-wise:
16:20:43 <Jaykul> there will be a category tree (possibly stolen from Microsoft's scriptcenter)
16:20:56 <RichardP> Jaykul: levels of code? (project, class, function or snippet?)
16:21:04 <Jaykul> there will be free-form tags (and logged in users will be able to tag anything)
16:21:13 <Jaykul> there will be comments on each submission
16:21:56 <Jaykul> there must be a button on every script contribution to "edit" it (ie: create a new contribution based on it)
16:23:51 <Jaykul> There will be levels of code (I have a list in the spreadsheet on http://docs.poshcode.org that I shared on the email list earlier, but I can't access it from here: snippet, function, script, module, and BINARY module.
16:23:54 <Jaykul> I think
16:24:18 *** PenPerk has joined the room as a participant and a member
16:24:37 <Jaykul> There will be multiple code languages present
16:25:34 <Jaykul> (at least PowerShell and .net langs: C#|VB|Python|Ruby, PLUS: VBScript and Perl)
16:25:52 <RichardP> Jaykul: can I suggest something?
16:26:09 <Jaykul> but there's no need to highlight that, except they'll be filterable in the search feature, of course
16:26:14 <Jaykul> yep
16:26:24 *Jaykul is logging this to put on the wiki
16:26:28 <RichardP> Jaykul: php documentation engine - steal heavily from it, its fucking awesome
16:27:09 <RichardP> and looks to be a large part of what you want - sure, theres lots of stuff you want on top, but its quite a way there. steal from it :)
16:27:30 *Jaykul nods
16:27:35 <Jaykul> so, on the front page (and on search results), each item will have:
16:27:42 <RichardP> and the layout is good as well
16:27:54 <Jaykul> * RANK (there will be user-voting, but not from the list pages)
16:28:13 <Jaykul> * Submitter (or "anonymous")
16:28:17 <Jaykul> * Title
16:28:27 <Jaykul> * The first line of the "Description"
16:29:06 <Jaykul> * Language (maybe an "icon" in the right-corner of the "box" for each submission?)
16:29:28 <RichardP> what icon could symbolise a language?
16:29:36 <RichardP> oh
16:29:38 <RichardP> heh
16:29:44 <palen> Powershell has the >_
16:29:45 <Jaykul> Well, like ">_" or "C#"
16:29:47 <RichardP> yeah, lancuage :)
16:29:56 <Jaykul> or "VB" or whatever
16:29:56 <palen> Ruby could be a ....ruby
16:30:03 <RichardP> I was thinking 'cant do country flags cos China has like a billion langauges'
16:30:20 <palen> Haha
16:30:23 <Jaykul> hehe
16:31:11 <Jaykul> * Links: 1) to the full details page, 2) direct to the download, 3) to the user profile of the submitter
16:31:36 <RichardP> Jaykul: how about an 'add to download package' feature as well?
16:31:39 <Jaykul> * Tags: at least the first 3 or so
16:31:55 <Jaykul> RichardP: uhm... how about for v2.2
16:31:56 <Jaykul> ;)
16:32:01 <RichardP> heh
16:32:26 <Jaykul> I have a hard deadline in May for this to be up
16:32:28 <Jaykul> ;)
16:32:41 <RichardP> hahahah
16:32:44 <RichardP> :D
16:32:51 *Jaykul sighs
16:32:54 <RichardP> why the hard deadline?
16:33:03 <palen> TechEd?
16:33:05 <Jaykul> Uhm...
16:33:11 *Jaykul whistles idle
16:33:16 <RichardP> heh
16:33:16 <palen> :o
16:33:22 <RichardP> oh yes
16:33:25 <RichardP> i do recall
16:33:34 <Jaykul> Lets just say ... there might be something big later in the summer
16:33:53 *** ghostz has left the room ("http://www.mibbit.com ajax IRC Client" (i=aab90e64@gateway/web/ajax/mibbit.com/x-44b5adf02bee9266))
16:33:56 <Jaykul> I should know for sure later this week
16:34:07 <RichardP> Jaykul: Im away this weekend, but I have all of next week and weekend to put some serious work in
16:34:08 <palen> I bet it has something to do with that interchange between Jaykul and hal about 'that thing only you and I know about'
16:34:23 <RichardP> palen: oh, other people know :)
16:35:38 <Jaykul> Yeah, there was a conf call earlier ...
16:36:05 *Jaykul trails off
16:36:15 <palen> Ominious
16:36:17 <Jaykul> and I don't want to talk about it for fear of jinxing it
16:36:20 <palen> And ominous
16:36:32 <palen> Fair enough
16:36:40 <Jaykul> but in any case, it involves getting this up sooner rather than later.
16:36:50 <RichardP> Jaykul: just one requestion - please please please dont make me do a tag cloud , they are only self propagating
16:37:04 <RichardP> oooh, new word - requestion :D
16:37:24 <Jaykul> self-propagating?
16:38:23 <RichardP> Jaykul: click on one, it gets bigger because its used, which means people are more likely to click on it, which means its more popular, which means it gets bigger, which means...
16:38:31 <Jaykul> oic
16:39:11 <Jaykul> We will have tagging, but I don't see any value in showing how often a tag gets used, or which tags are more popular
16:39:57 <RichardP> i have no issue with tagging, or even showing in a list whats more popular, but tag clouds are horrible things
16:40:05 <Jaykul> hehe
16:40:21 <Jaykul> Fine with me :)
16:40:42 <Jaykul> OK, so ... I think that mostly covers the ... "list" pages
16:41:18 <Jaykul> the actual details pages are going to need to show ... all the data in that Dublin Core document
16:41:20 <palen> Wow
16:41:22 <Jaykul> plus the script
16:41:30 <palen> Some people have no filter on their bug reports...
16:41:34 <Jaykul> (or scripts, at some point)
16:41:36 *** pantocrator has joined the room as a participant and a member
16:42:05 <pantocrator> hi
16:43:25 <Jaykul> hi
16:44:48 <Jaykul> RichardP: Two interesting UI-type things I want to try: 1) "derivative scripts" (ala github: show how many people have posted new versions of, or new contributions based on "this" contribution (this is important for May)) 2) a "edit history" timeline ... as a way to show the "previous versions" of a script.
16:45:23 <palen> Oo, oo, could we hook them up to NodeXL?
16:45:26 <RichardP> Jaykul: 3) 'where has this code been used elsewhere?'
16:45:34 <Jaykul> For the timeline thing we might be able to borrow from the chandler project thing
16:45:46 <Jaykul> Or make something in Silverlight
16:45:53 <Jaykul> for either, or both
16:46:01 <Jaykul> palen: Hmmm!
16:47:48 <palen> And a ZUI
16:47:57 <Jaykul> deepzoom
16:48:15 <Jaykul> ooh, timelines for users ...
16:48:27 <Jaykul> that would be cool
16:48:34 <Jaykul> we will want profile pages for users
16:48:52 <Jaykul> and a "diff" page
16:49:04 <palen> Profiles optionally linked to twitter?
16:49:17 <RichardP> oh god, please dont include any social networking stuff ;)
16:49:25 <Jaykul> profiles will include twitter ids
16:49:26 <palen> Haha
16:49:32 <Jaykul> but I dono about anything else
16:49:33 <palen> Ha, I win!
16:49:46 *RichardP sharpens his stabby thing
16:49:46 <Jaykul> the PoshCode bot already posts on twitter
16:49:53 <Jaykul> whenever someone contributes
16:50:08 <Jaykul> Twitter is the new, suckier, RSS

Updated Wiki: Requirements

Jaykul — Mon, 16 Mar 2009 20:51:54 GMT

Requirements for PoshCode Repository

First Requirements Meeting Notes

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

I think we can store a lot of the data we want to store as special key:value "tags" so we can render them to the scripts in "data language" or comments (or data language in comments). I think we should consider "Machine Tags"1 as a way to make this extensible by third party repositories.

General Requirements:

Easy in, Easy out, Low Barriers (no mandatory registration, no login to download).
Multi-file artifacts (script modules [[4]]).
Browsing and Searching in the WebUI.

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules([[5]])
- The version 2 ... ScriptFileID and ModuleID
- The date of submission (for ordering)
- The author (OpenID url? email address?)
? Function and/or Cmdlet Name(s)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)
- Nouns!
? License? (offer a selection: CC, Ms, GPL, etc., and prepend a "short form" license comment).
? Feedback (Comments, Ratings)

Third Party Modules

Info URL

? Download Url (for v2?)

Version Optional

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

The goal is to define a standard web service api that anyone can implement (this means not making the API technology independent -- so you can implement it and call it from Asp/Wcf/Php/PowerShell/C#/Whatever).

The API should support:

- searching and browsing (by author, verb, noun, tag, fulltext)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading (by id)
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow -- should validate mandatory data)
? commenting
? tagging

User Interface

At a minimum we need a WebUI and Cmdlets for accessing the API. Ideally they would be implemented strictly against the API so either the WebUI or the cmdlets could access any implementation of it. Perhaps we should not open source the WebUI (or should make it strictly GPL?). Additionally, there are some other ideas...

Stats (for convincing people to support "our" repository)

Number of Authors
Number of Postings (rate per day, total count, unique scripts not counting versions)
Downloads, (Script) Page Views?
RSS subscribers?

Claims Based Trust

Could there be a way to verify claims about scripts? using the tokenizer? using trusted authors? Eg: we could create a claims system where the uploader claims:
A. Doesn't use .Net classes
B. Doesn't modify files
C. Doesn't modify registry settings
... or whatever. Some claims could be automatically validated, and some would need to be validated by users/authors, and/or ...

Should we sign the data we embed in the scripts? That is, sign our portion of the data for our own sake -- so we can track history and authorship (based on logins) with confidence.

Footnotes

Machine Tags: (see [Wikipedia|url:http://en.wikipedia.org/wiki/Machine_tag] and the original post on [flickr|url:http://www.flickr.com/groups/api/discuss/72157594497877875/]) might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
Versioning: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
Dependencies: The module or script dependencies should be URLs or the hashes from 2, and could probably be deduced from "#requires http://URL" in the comments.
Script modules: (and modules in general) require some system for storing multiple files as part of a single "artifact", and for downloading them all at once. We also need to track versioning of the "whole" package, and have an API/interface for uploading them, viewing them, and downloading them (I'm not sure if we really need to support downloading single files from a multi-file artifacts, but obviously in a WebUI you'd want to be able to show the source if it was a script module, right?)
Compiled modules: Do we support compiled modules in any way? If so, how? We do NOT compile, but do we provide full source packages? They could include a MSBuild file (like a visual studio project file) and the cmdlet could hypothetically compile it. How about modules like PSCX (which is open source, but has source control elsewhere), could we (safely) provide a ScriptInfo with download URL pointing to the project's hosting? What about commercial projects? We can put off deciding this stuff until after V1 is out ;-)

Updated Wiki: CurrentWork

Jaykul — Sat, 08 Nov 2008 16:28:17 GMT

Joel to create a DB Schema and Dynamic Data Service

DbSchema Ok, how about everyone else?

Oisin to also look into how AtomPub maps from ADO Dynamic Data and WCF

Robbie to look into OpenSearch and AtomPub

We should probably look into http://pkok.wordpress.com/2008/11/07/lucenenet-resources/ for full-text search, unless someone knows better than I do how to make a "Google Like" search based on SQL's full-text search -- search on the current PoshCode.org is based on MySQL's full-text, and it's annoyingly odd

Mark to look into AtomPub and Authentication -- how those map to WCF or ADO

Updated Wiki: DbSchema

Jaykul — Fri, 24 Oct 2008 03:18:10 GMT

First "draft" of a database schema ...

Updated Wiki: Home

Jaykul — Sat, 13 Sep 2008 20:47:30 GMT

PoshCode is a PowerShell-centric code-snippet storage web service. The primary goal is to store code snippets, scripts, and/or modules (collectively, artifacts) and provide access to them from within PowerShell. This project serves as the coordination point for our effort to develop a standard API for such services, as well as a baseline implementation of the API, and a sample set of client implementations (at a minimum: web, cmdlets).

We're re-working our Requirements right now, and will post more on the front page when we have something more interesting to share ;-)

What we're Currently Working on is some research into the protocols and technologies we want to use.

Updated Wiki: CurrentWork

Jaykul — Sat, 13 Sep 2008 20:46:11 GMT

Joel to create a DB Schema and Dynamic Data Service

Oisin to also look into how AtomPub maps from ADO Dynamic Data and WCF

Robbie to look into OpenSearch and AtomPub

Mark to look into AtomPub and Authentication -- how those map to WCF or ADO

Updated Wiki: Requirements

Jaykul — Sat, 13 Sep 2008 20:09:49 GMT

Requirements for PoshCode Repository

First Requirements Meeting Notes

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

General Requirements:

Easy in, Easy out, Low Barriers (no mandatory registration, no login to download).
Multi-file artifacts (script modules [[4]]).
Browsing and Searching in the WebUI.

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules([[5]])
- The version 2 ... ScriptFileID and ModuleID
- The date of submission (for ordering)
- The author (OpenID url? email address?)
? Function and/or Cmdlet Name(s)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)
- Nouns!
? License? (offer a selection: CC, Ms, GPL, etc., and prepend a "short form" license comment).
? Feedback (Comments, Ratings)

Third Party Modules

Info URL

? Download Url (for v2?)

Version Optional

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

- searching and browsing (by author, verb, noun, tag, fulltext)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading (by id)
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow -- should validate mandatory data)
? commenting
? tagging

User Interface

Stats (for convincing people to support "our" repository)

Number of Authors
Number of Postings (rate per day, total count, unique scripts not counting versions)
Downloads, (Script) Page Views?
RSS subscribers?

Claims Based Trust

Footnotes

Machine Tags: (see [Wikipedia|url:http://en.wikipedia.org/wiki/Machine_tag] and the original post on [flickr|url:http://www.flickr.com/groups/api/discuss/72157594497877875/]) might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
Versioning: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
Dependencies: The module or script dependencies should be URLs or the hashes from 2, and could probably be deduced from "#requires http://URL" in the comments.
Script modules: (and modules in general) require some system for storing multiple files as part of a single "artifact", and for downloading them all at once. We also need to track versioning of the "whole" package, and have an API/interface for uploading them, viewing them, and downloading them (I'm not sure if we really need to support downloading single files from a multi-file artifacts, but obviously in a WebUI you'd want to be able to show the source if it was a script module, right?)
Compiled modules: Do we support compiled modules in any way? If so, how? We do NOT compile, but do we provide full source packages? They could include a MSBuild file (like a visual studio project file) and the cmdlet could hypothetically compile it. How about modules like PSCX (which is open source, but has source control elsewhere), could we (safely) provide a ScriptInfo with download URL pointing to the project's hosting? What about commercial projects? We can put off deciding this stuff until after V1 is out ;-)

Updated Wiki: Requirements

Jaykul — Sat, 13 Sep 2008 19:49:13 GMT

Requirements for PoshCode Repository

First Requirements Meeting Notes

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

General Requirements:

Easy in, Easy out, Low Barriers (no mandatory registration, no login to download).
Multi-file artifacts (script modules [[4]]).
Browsing and Searching in the WebUI.

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules([[5]])
- The version 2 ... ScriptFileID and ModuleID
- The date of submission (for ordering)
- The author (OpenID url? email address?)
? Function and/or Cmdlet Name(s)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)
- Nouns!
? License? (offer a selection: CC, Ms, GPL, etc., and prepend a "short form" license comment).
? Feedback (Comments, Ratings)

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

- searching and browsing (by author, verb, noun, tag, fulltext)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading (by id)
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow -- should validate mandatory data)
? commenting
? tagging

User Interface

Stats (for convincing people to support "our" repository)

Number of Authors
Number of Postings (rate per day, total count, unique scripts not counting versions)
Downloads, (Script) Page Views?
RSS subscribers?

Claims Based Trust

Footnotes

Machine Tags: (see [Wikipedia|url:http://en.wikipedia.org/wiki/Machine_tag] and the original post on [flickr|url:http://www.flickr.com/groups/api/discuss/72157594497877875/]) might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
Versioning: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
Dependencies: The module or script dependencies should be URLs or the hashes from 2, and could probably be deduced from "#requires http://URL" in the comments.
Script modules: (and modules in general) require some system for storing multiple files as part of a single "artifact", and for downloading them all at once. We also need to track versioning of the "whole" package, and have an API/interface for uploading them, viewing them, and downloading them (I'm not sure if we really need to support downloading single files from a multi-file artifacts, but obviously in a WebUI you'd want to be able to show the source if it was a script module, right?)
Compiled modules: Do we support compiled modules in any way? If so, how? We do NOT compile, but do we provide full source packages? They could include a MSBuild file (like a visual studio project file) and the cmdlet could hypothetically compile it. How about modules like PSCX (which is open source, but has source control elsewhere), could we (safely) provide a ScriptInfo with download URL pointing to the project's hosting? What about commercial projects? We can put off deciding this stuff until after V1 is out ;-)

Updated Wiki: First Requirements Meeting Notes

Jaykul — Thu, 11 Sep 2008 14:52:29 GMT

Pre-meeting missive

The main point of this meeting (apart from introducing ourselves) should be a discussion of the Web Service API -- we need to hammer this down so we can get started writing code. Of course, we also need to talk about who's willing to handle what parts of the code (no, you can't all work on the cmdlets).

In order to make that conversation easier to have, we ask that you will all have at least looked over what we have so far on our requirements page Requirements so we can just jump right into anything you see which either needs to change or needs more detail.

In particular, we need to be thinking about :

What data needs to be a part of the API? (author, download url, Cmdlet/Function name(s), what else?)
How we handle different TYPES of code artifacts: Module, Script, Function, Snippet ... do we need to separate the idea of a "sample snippet" out of our main API so that we can make something useful? That is: Should we make a single "function" (or external script -- which is actually treated as a function if it's in your path) the smallest unit of code that we talk about?
What should the WebService API look like? (implementable in any web language: asp.net/wcf/php, easy to consume ... need "search" and "get" commands, what else?)

Don't forget: we're trying to create a WebService API that is easy enough to implement and work with that everyone who considers creating a PowerShell script repository would be motivated to implement it.

Step one in this is to create a sort-of contract for what information is going to have to be in our "PoshCodeInfo" object. Bear in mind that a this object is somewhat like a PSModuleInfo object (the output of Get-Module in CTP2):

PSModuleInfo:		PoshCodeInfo
Exports	A list of the cmdlets/functions/variables	Exports	A collection of CommandInfo objects
IsCompiledCode	Boolean: yes/no	CodeType	Script/Compiled/Source
Name	The module name	Name	The name assigned by the uploader
Path	The file location	Url	The link to download from (downloads THIS version?)
		Version	A Hash: the version number and hash
		UpdateUrl	The Url to check for new versions (can be the same as the Url)
		Date	The date of upload
		Author	UserName or OpenID
		Tags	A list of tags, including Noun:XXX and Verb:XXX ?

The simplest thing for us would be to just add Date, Author, and URL and call it a day, but we probably want to have a little more information about the cmdlets/functions that are in the module. In CTP2 you can do: Get-Module | Select -Expand Exports | Get-Command ... unless we can think of a way to do that for the Cmdlets that are in a module on our server, we may want to include the information about them in our PoshCodeInfo object -- would we then want to have a separate lighter set of data we return from a search? (lets talk about it tonight -- see the wiki for my current thought).

Other examples of script information you could look at are the objects returned from: gcm * | gm ... particularly CmdletInfo and ExternalScriptInfo.

My feeling right now is that we will want our API to output these "objects" in a relatively human-readable (xml) serialization format which the cmdlets/apps could then re-render as PoshCodeInfo objects ... in my ideal world this would mean that we or others can EXTEND the data in the object later on without breaking applications written against the base API. That said, we would dearly like to get this right the ahem third time around ;-) (that is, this time, for those of you not keeping score).

TO SUM UP:

Think about what the PSModuleInfo object and CmdletInfo object look like. What needs to be added to that so that an end user could figure out whether they want to download the actual script, and how to download it.
Think about how we and end users will store this data, will tags and "machine tags" work? Do you like the idea (as written in the requirements on the wiki) of (mis)using them to store all sorts of extra data -- which might be specific to a given implementation of the service?
How much data do we want send over in search results. What about "dependencies"?
Think about ways to embed the data with the downloaded files!!

PS v2 has a concept of a "data manifest" for modules, but that may already be a part of the uploaded code.
We need to handle this differently for multi-file modules than for scripts -- we need to EMBED the data in the script, whereas a module could have a separate file, since a module gets extracted to it's own folder.
Can we just embed the meta data, in PSD1 format, in a comment block at the top of the file (at the top of the .psd1 file if you upload a module), and have a script/cmdlet which can extract that data and show it to the end user if they ask for information about a script?

Can we design this so that the cmdlets will work with metadata objects in scripts and allow you to check "any" server for a new version?

You could put metadata in a script file you host on your blog that just points to a file on your webserver, or that points to our web-service.
We could serve up metadata in our search results about modules which we don't host (PSCX?) which would tell you what's in them, and where to get them.
PSCX could include our metadata in their PSD1 file, and our cmdlets would be able to check for and optionally download an updated version

Just for today ... lets not talk about script signing at all ;-)

Meeting Notes

Updated Wiki: Requirements

Jaykul — Thu, 11 Sep 2008 14:34:45 GMT

Requirements for PoshCode Repository

First Requirements Meeting Notes

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

General Requirements:

Easy in, Easy out, Low Barriers (no mandatory registration, no login to download).
Multi-file artifacts (script modules [[4]]).
Browsing and Searching in the WebUI.

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules([[5]])
- The version 2
- The date of submission (for ordering)
- The author (OpenID url? email address?)
? Function and/or Cmdlet Name(s)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)
- Nouns!
? License? (offer a selection: CC, Ms, GPL, etc., and prepend a "short form" license comment).
? Feedback (Comments, Ratings)

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

- searching and browsing (by author, verb, noun, tag, fulltext)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading (by id)
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow -- should validate mandatory data)
? commenting
? tagging

User Interface

Stats (for convincing people to support "our" repository)

Number of Authors
Number of Postings (rate per day, total count, unique scripts not counting versions)
Downloads, (Script) Page Views?
RSS subscribers?

Claims Based Trust

Footnotes

Machine Tags: (see [Wikipedia|url:http://en.wikipedia.org/wiki/Machine_tag] and the original post on [flickr|url:http://www.flickr.com/groups/api/discuss/72157594497877875/]) might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
Versioning: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
Dependencies: The module or script dependencies should be URLs or the hashes from 2, and could probably be deduced from "#requires http://URL" in the comments.
Script modules: (and modules in general) require some system for storing multiple files as part of a single "artifact", and for downloading them all at once. We also need to track versioning of the "whole" package, and have an API/interface for uploading them, viewing them, and downloading them (I'm not sure if we really need to support downloading single files from a multi-file artifacts, but obviously in a WebUI you'd want to be able to show the source if it was a script module, right?)
Compiled modules: Do we support compiled modules in any way? If so, how? We do NOT compile, but do we provide full source packages? They could include a MSBuild file (like a visual studio project file) and the cmdlet could hypothetically compile it. How about modules like PSCX (which is open source, but has source control elsewhere), could we (safely) provide a ScriptInfo with download URL pointing to the project's hosting? What about commercial projects? We can put off deciding this stuff until after V1 is out ;-)

Updated Wiki: Requirements

Jaykul — Sun, 07 Sep 2008 03:30:54 GMT

Requirements for PoshCode Repository

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

General Requirements:

Easy in, Easy out, Low Barriers (no mandatory registration, no login to download).
Multi-file artifacts (script modules [[4]]).
Browsing and Searching in the WebUI.

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules([[5]])
- The version 2
- The date of submission (for ordering)
- The author (OpenID url? email address?)
? Function and/or Cmdlet Name(s)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)
- Nouns!
? License? (offer a selection: CC, Ms, GPL, etc., and prepend a "short form" license comment).
? Feedback (Comments, Ratings)

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

- searching and browsing (by author, verb, noun, tag, fulltext)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading (by id)
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow -- should validate mandatory data)
? commenting
? tagging

User Interface

Stats (for convincing people to support "our" repository)

Number of Authors
Number of Postings (rate per day, total count, unique scripts not counting versions)
Downloads, (Script) Page Views?
RSS subscribers?

Claims Based Trust

Footnotes

Machine Tags: (see [Wikipedia|url:http://en.wikipedia.org/wiki/Machine_tag] and the original post on [flickr|url:http://www.flickr.com/groups/api/discuss/72157594497877875/]) might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
Versioning: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
Dependencies: The module or script dependencies should be URLs or the hashes from 2, and could probably be deduced from "#requires http://URL" in the comments.
Script modules: (and modules in general) require some system for storing multiple files as part of a single "artifact", and for downloading them all at once. We also need to track versioning of the "whole" package, and have an API/interface for uploading them, viewing them, and downloading them (I'm not sure if we really need to support downloading single files from a multi-file artifacts, but obviously in a WebUI you'd want to be able to show the source if it was a script module, right?)
Compiled modules: Do we support compiled modules in any way? If so, how? We do NOT compile, but do we provide full source packages? They could include a MSBuild file (like a visual studio project file) and the cmdlet could hypothetically compile it. How about modules like PSCX (which is open source, but has source control elsewhere), could we (safely) provide a ScriptInfo with download URL pointing to the project's hosting? What about commercial projects? We can put off deciding this stuff until after V1 is out ;-)

Updated Wiki: Requirements

Jaykul — Sun, 07 Sep 2008 03:27:35 GMT

Requirements for PoshCode Repository

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

General Requirements:

Easy in, Easy out, Low Barriers (no mandatory registration, no login to download).
Multi-file artifacts (script modules [[4]]).
Browsing and Searching in the WebUI.

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules([[5]])
- The version 2
- The date of submission (for ordering)
- The author (OpenID url? email address?)
? Function and/or Cmdlet Name(s)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)
- Nouns!
? License? (offer a selection: CC, Ms, GPL, etc., and prepend a "short form" license comment).
? Feedback (Comments, Ratings)

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

- searching and browsing (by author, verb, noun, tag, fulltext)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading (by id)
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow -- should validate mandatory data)
? commenting
? tagging

User Interface

Stats (for convincing people to support "our" repository)

Number of Authors
Number of Postings (rate per day, total count, unique scripts not counting versions)
Downloads, (Script) Page Views?
RSS subscribers?

Claims Based Trust

Footnotes

Machine Tags: see http://en.wikipedia.org/wiki/Machine_tag and http://machinetags.org/ and http://www.flickr.com/groups/api/discuss/72157594497877875/ might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
Versioning: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
Dependencies: The module or script dependencies should be URLs or the hashes from 2, and could probably be deduced from "#requires http://URL" in the comments.
Script modules: (and modules in general) require some system for storing multiple files as part of a single "artifact", and for downloading them all at once. We also need to track versioning of the "whole" package, and have an API/interface for uploading them, viewing them, and downloading them (I'm not sure if we really need to support downloading single files from a multi-file artifacts, but obviously in a WebUI you'd want to be able to show the source if it was a script module, right?)
Compiled modules: Do we support compiled modules in any way? If so, how? We do NOT compile, but do we provide full source packages? They could include a MSBuild file (like a visual studio project file) and the cmdlet could hypothetically compile it. How about modules like PSCX (which is open source, but has source control elsewhere), could we (safely) provide a ScriptInfo with download URL pointing to the project's hosting? What about commercial projects? We can put off deciding this stuff until after V1 is out ;-)

Updated Wiki: Requirements

Jaykul — Sun, 07 Sep 2008 03:19:51 GMT

Requirements for PoshCode Repository

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

General Requirements:

Easy in, Easy out, Low Barriers (no mandatory registration, no login to download).
Multi-file artifacts (script modules [[4]]).
Browsing and Searching in the WebUI.

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules([[5]])
- The version 2
- The date of submission (for ordering)
- The author (OpenID url? email address?)
? Function and/or Cmdlet Name(s)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)
- Nouns!
? License? (offer a selection: CC, Ms, GPL, etc., and prepend a "short form" license comment).
? Feedback (Comments, Ratings)

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

- searching and browsing (by author, verb, noun, tag, fulltext)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading (by id)
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow -- should validate mandatory data)
? commenting
? tagging

User Interface

Stats (for convincing people to support "our" repository)

Number of Authors
Number of Postings (rate per day, total count, unique scripts not counting versions)
Downloads, (Script) Page Views?
RSS subscribers?

Claims Based Trust

Footnotes

{Machine Tags:MachineTags}: see http://en.wikipedia.org/wiki/Machine_tag and http://machinetags.org/ and http://www.flickr.com/groups/api/discuss/72157594497877875/ might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
{Versioning:Versioning}: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
{Dependencies:Dependencies}: The module or script dependencies should be URLs or the hashes from 2, and could probably be deduced from "#requires http://URL" in the comments.
{Script modules:ScriptModules} (and modules in general) require some system for storing multiple files as part of a single "artifact", and for downloading them all at once. We also need to track versioning of the "whole" package, and have an API/interface for uploading them, viewing them, and downloading them (I'm not sure if we really need to support downloading single files from a multi-file artifacts, but obviously in a WebUI you'd want to be able to show the source if it was a script module, right?)
{Compiled modules:CompiledModules} Do we support compiled modules in any way? If so, how? We do NOT compile, but do we provide full source packages? They could include a MSBuild file (like a visual studio project file) and the cmdlet could hypothetically compile it. How about modules like PSCX (which is open source, but has source control elsewhere), could we (safely) provide a ScriptInfo with download URL pointing to the project's hosting? What about commercial projects? We can put off deciding this stuff until after V1 is out ;-)

Updated Wiki: Requirements

Jaykul — Sat, 06 Sep 2008 21:02:20 GMT

General Notes

KEY:

items with - are things we NEED to have
items with + are things that would be nice
items with ? are things we need to DECIDE about

Data

This is the list of things we want to know about a script (ie: data we need to store

- The script itself. Scripts, snippets, examples, modules, compiled modules(?)
- The version 2
- The date of submission (for ordering)
- The author (OpenID url? email address?)
- A description
? Usage (i.e. the -? help...)
? Example (do we really need to ask for these things separately? Shouldn't they put it into comments or a -? argument handler?)
+ Dependencies (PowerShell version, .Net Version, module or scripts)3
+ User Tagging (including non-authors?)

We would like to persist some of this data for people who download the artifacts ... either by embedding it in comments, or by including a psd1 manifest.

Web Service API

- searching and browsing (by author, verb, noun, tag)
- summaries (we need a "ScriptInfo" object: description, author, date, id/hash, version...)
- downloading
- authentication (note that OpenID requires Web UI)
- uploading (with all the data, somehow)
? commenting
? tagging

User Interface

Claims Based Trust

Footnotes

{Machine Tags:MachineTags}: see http://en.wikipedia.org/wiki/Machine_tag and http://machinetags.org/ and http://www.flickr.com/groups/api/discuss/72157594497877875/ might let us differentiate tags that are about required libraries, etc ... but would also let other repositories extend the storage and still store the data in a way we could use. E.g.: Use our web domain for as the namespace so if there are many compatible sites, poshcode.org could have tags like "WMI" and "VMWare" and "WPF" ... but also like "requires:VIToolkit" or "requires:2.0" or "requires:PSCX" ... and could store them in the script as poshcode.org=tag:WMI, poshcode.org=requires:PSCX etc.
{Versioning:Versioning}: J. Snover had a good idea about versioning, to hash the script body and use the hash as the id of the script ... The idea is that you would then insert that as a comment into script (header? footer?), and when someone submits a script that already has an id line in it, you could assume the new script is a new version of that script, and you could keep them all there, as a history of versions for tracking scripts. We could store that as an indexed field in the db and use it in urls too: It would be practically unique, but portable across sites for unmodified scripts!
{Dependencies:Dependencies}: The module or script dependencies should be URLs or the hashes from 2

Updated Wiki: Home

Jaykul — Sat, 06 Sep 2008 21:01:35 GMT

UPDATED WIKI: web UI

Jaykul — Thu, 22 May 2008 17:41:42 GMT

One of our core concepts is that the back end will be based on WCF -- this is partly for functionality, and partly to motivate the Open Source developers that are writing it, because we like the idea of using this to further our familiarity with the technology. However, there will be a Web front-end, and one of the questions that has come up is whether the Web UI "View" Layer should talk to the controller layer exclusively through WCF.

Here's the tentative answer:

The web front end should be written so that it could communicate with the server exclusively through WCF. It should be written against the WCF interface, but for now, it can have a direct reference to the WCF "server" implementation, so that it doesn't need to use networking to "communicate" with the view layer. This way, if the need arises later on for the web UI to be moved to a different server than the service is running on, it should be a matter of a few tweaks to the code to run it remotely.

UPDATED WIKI: Verb-Noun

Jaykul — Thu, 22 May 2008 17:36:38 GMT

We are currently handling verb/noun by using tagging, and I think that's the way it should stay ... it doesn't provide referential integrity, but since we're not concerned with preventing multiple people from writing a dozen different implementations of Get-Web or Send-Tweet, that's not a problem.

Basically, this is how it works: if you upload a script module that has three functions or cmdlets in it:

Add-Widget
Get-Widget
Remove-Widget

You would need to specify these names to the PowerShell-specific upload UI (or cmdlet) and it would be stored with the following tags:

Noun:Widget
Verb:Add
Verb:Get
Verb:Remove

The idea is that the cmdlets and WebUI will make it so you don't have to be particularly aware of that by allowing you to "Search by Noun" and then taking your noun and doing a tag search by Noun:YourNoun

UPDATED WIKI: Verb-Noun

Jaykul — Thu, 22 May 2008 17:36:23 GMT

Add-Widget
Get-Widget
Remove-Widget

You would need to specify these names to the PowerShell-specific upload UI (or cmdlet) and it would be stored with the following tags:
*Noun:Widget
*Verb:Add
*Verb:Get
*Verb:Remove

The idea is that the cmdlets and WebUI will make it so you don't have to be particularly aware of that by allowing you to "Search by Noun" and then taking your noun and doing a tag search by Noun:YourNoun

UPDATED WIKI: Home

Jaykul — Thu, 22 May 2008 17:32:39 GMT

PoshCode is a code-snippet storage system with the primary goal of storing code snippets and providing access to snippets from within PowerShell. It will also have a web UI, and will support tagging and snippet versioning.

ToDo list:

Initial public release

Be able to retrieve code snippets by id (completed)
Be able to add code snippets specifying all fields(completed)

Validate "required" fields at the client end
Authenticate authors

Be able to return partial snippets based on search
Provide a client implementation (probably PowerShell cmdlets which work with strings in the pipeline)

Post release

Snippet Versioning (ability to submit new versions of existing snippets)
A web UI

Including snippet submission
Including snippet search

Script browsing by Author, Language, Verb-Noun, Tag -- or any mix of these (including search terms?)
Color-syntax highlighting (for the web)