https://microformats.org/wiki/api.php?action=feedcontributions&user=JasonK&feedformat=atomMicroformats Wiki - User contributions [en]2024-03-29T11:12:49ZUser contributionsMediaWiki 1.38.4https://microformats.org/wiki/index.php?title=rest/brainstorming&diff=31495rest/brainstorming2007-01-10T20:27:51Z<p>JasonK: /* Constraints */</p>
<hr />
<div>= XHTML-REST Brainstorming =<br />
<br />
This page collects ideas from [[rest-examples]] how to best encode [[REST]] data in an XHTML microformat.<br />
<br />
== Constraints ==<br />
<br />
The underlying premise of this investigation is that REST is less useful that it could be due to concerns about a) interoperability, and b) discoverability. To address this, we propose adopting microformat-style conventions to further constrain the ways REST already constrains web services.<br />
<br />
In particular, we constrain REST to work with existing web browser clients -- yet also be machine-parseable. This means:<br />
* All inputs must be url-encoded (or maybe mime/multipart)<br />
* All output must be XHTML, either:<br />
** XOXO: [[xoxo]] (dl, ul, ol)<br />
** XOXT: [[table-brainstorms]] (table-th-tr-td)<br />
* All URI links must be encoded as either:<br />
** Anchors (&lt;a&gt;) (via 'href')<br />
** Forms (&lt;a&gt;) (via 'action')<br />
* Only GET and POST actions are supported<br />
<br />
This may seem very strict, but that's the point: by adding more constraints, we reduce gratuitous degrees of freedom and enable greater consistency.<br />
<br />
This may not solve every conceivable problem, but it should handle the 50% case pretty well:<br />
* REST: 80% of web services<br />
* XHTML: 80% of XML expressiveness<br />
* GET/POST + urlencoding: 80% of queries<br />
or, put another way:<br />
* 80% x 80% x 80% = 51.2% of the benefit for<br />
* 20% x 20% x 20% = 0.8% of the effort<br />
<br />
== Conventions ==<br />
<br />
To make parsing and auto-discovery easier -- and also simplify the design process -- we propose the following additional conventions.<br />
<br />
=== Nouns ===<br />
<br />
As usual in REST, every ''noun'' must be a URI. However, we explicitly define three types of URIs:<br />
;base:The base URI for the web service, e.g.: <code>http://example.com/site/</code>.<br />
;records:URIs representing individual entities, e.g.: <code>http://example.com/webservice/users/me%40drernie.com</code>.<br />
;tables:The URIs used to create or search for those instances, e.g.: <code>http://example.com/webservice/users</code>.<br />
<br />
Note that each record is defined by a set of key-value pairs living under that table.<br />
<br />
There can also be 'singletons' - a class which only has a single instance.<br />
<br />
=== Verbs ===<br />
<br />
REST depends on using verbs properly. Your typical verbs are POST (create), GET (retrieve), PUT (update), and DELETE (delete). More verbs can be defined and used, but the listed above are most commonly used and supported.<br />
<br />
As we know, HTML forms spec (and therefore commonly used UAs) only provides support for POST and GET verbs. This limitation has been the biggest argument against mixing HTML and REST: tunnelling of PUT and DELETE verbs through POST (or even worse, GET) creates architectural unREST.<br />
<br />
However, some architectures simply do not need deletion and update operations. Using HTML with REST requires employing such architectures.<br />
<br />
While that may seem overly restrictive, as a practical matter those cover the "80%" of public web services we are trying to solve (after all, you are welcome to use your own private methods if you need to).<br />
<br />
Even better, we can define very precise semantics for what GET & POST mean for each of the different nouns:<br />
<br />
GET base<br />
GET base?view=api # Return hyperlinks and forms<br />
GET base?query # search for records across multiple table<br />
<br />
GET table<br />
GET table?view=api<br />
GET table?query # search for records in that table<br />
POST table?create # create record<br />
<br />
GET record # encode as xoxo<br />
GET record?view=edit # encode as hyperlinks/anchors<br />
GET record?view=api # encode as hyperlinks/anchors + descriptions<br />
POST record?update # update record -- this is tunnelling, a no-no<br />
<br />
For simplicity, we assume:<br />
* users can not delete anything<br />
* users can not create tables (or singletons)<br />
<br />
To be sure, there are natural ways to extend this protocol to provide that functionality. However, as that is primarly for admin usage, and thus a private API, we're glossing over it here. From a user's point of view, we provide analogous capabilities using POST:<br />
* "DELETE" is replaced by "mark for deletion"<br />
* "PUT" is replaced by "ask table to create record"<br />
<br />
=== Format ===<br />
<br />
Results should be returned in a xoxo-compatible format. In particular, query results should leverage <br />
[http://opensearch.a9.com/spec/opensearchresponse/1.1/ OpenSearch 1.1]. <br />
<br />
[''Do HTML bindings for this already exist?'']<br />
<br />
== Questions for further research ==<br />
<br />
== Patterns ==<br />
<br />
=== Anchor Design Pattern ===<br />
<br />
&lt;a class="rest" href="http//somesite.com/prog/adduser">label&lt;/a><br />
<br />
=== Forms Design Pattern ===<br />
<br />
I use a number of <form>s to declare the API for a web resource:<br />
<br />
<div class="function"><br />
The visual human name in h1-tags:<br />
<br />
<h1>Foobalize</h1><br />
<br />
A human readable explanation using in some html.<br />
<br />
<p>Foobalizer foobalizes grunts and glomph. Note that blorks already must be gazzed!<br />
</p><br />
<br />
Then the form that specifies one function:<br />
<br />
<form id="fooblize" action="GET" action="http://www.example.com/glurt"><br />
<div class="field"><br />
<label for="grunt">Grunt</label> <input type="text" class="varchar(20)" /><br />
</div><br />
<div class="field"><br />
<label for="grunt">Blork</label> <input type="text" class="int4" /><br />
</div><br />
<input type="submit" value="Foobalize" /><br />
</form><br />
<br />
</div><br />
<br />
== See Also ==<br />
<br />
* [http://www.opendarwin.org/~drernie/rest-api.html REST self-describing API proposal]<br />
* [http://opensearch.a9.com/ OpenSearch search results standard (REST-like)]<br />
* [[rest-proposal-preso]]<br />
* [[duhper-proposal-preso]]<br />
<br />
[http://www.opendarwin.org/~drernie/rest-api.html Proposed REST API]</div>JasonKhttps://microformats.org/wiki/index.php?title=rest/examples&diff=14275rest/examples2007-01-10T14:52:53Z<p>JasonK: /* See Also */</p>
<hr />
<div>= XHTML-REST Examples =<br />
<br />
These are some examples of how people are currently implementing [http://en.wikipedia.org/wiki/Representational_State_Transfer#REST_versus_RPC REST] web services (usually in XML), to provide some context for how best to implement them in XHTML.<br />
<br />
== The Problem ==<br />
<br />
Quoting the wikipedia [http://en.wikipedia.org/wiki/Representational_State_Transfer#REST_versus_RPC REST] article:<br />
: In general, however, REST for data does not yet have a generally-accepted, standard format corresponding to HTML for documents, so each REST client must be custom-written to deal with XML at a fairly low level, and crawling XML data over REST is difficult (since it is not always easy to identify links). Proposals for a standard, generic format for use with REST based systems have included RDF, XTM, Atom, RSS (in its various flavours), and Plain Old XML (POX) with XLink to handle links<br />
<br />
In short, there isn't a clean design pattern for the optimal way to encode and use REST, which is precisely the sort of thing a microformats approach can provide.<br />
<br />
== Participants ==<br />
* [mailto:drernie@opendarwin.org Dr. Ernie Prabhakar]<br />
* [mailto:luke.arno@gmail.com Luke Arno]<br />
* [mailto:dimitri.glazkov@gmail.com Dimitri Glazkov]<br />
<br />
== Real-World Examples ==<br />
''Links to public web pages, either popular or insightful''<br />
<br />
=== [http://tools.ietf.org/wg/atompub/draft-ietf-atompub-protocol/ ATOM Publishing] ===<br />
Currently the best use of REST in a standard protocol.<br />
They're even discussing using XOXO!<br />
<br />
=== [http://images.amazon.com/images/G/media/i3d/01/associates/ecs-dg-20051005.pdf Amazon E-Commerce] ===<br />
<br />
Not a very good example, as they only have a single URI for the "REST" API, and do everything with url-encoding.<br />
<br />
=== [http://del.icio.us/doc/api Delicious API] ===<br />
<br />
Their so-called REST API is not, really. Here's a good critique which includes a more RESTful representation:<br />
<br />
http://www.peej.co.uk/articles/restfully-delicious<br />
<br />
== Existing Practices ==<br />
* ''Summary of common patterns discovered''<br />
* ''Other attempts to solve The Problem''<br />
== Proposal ==<br />
* Early drafts<br />
* ''Link to related pages as they become available''<br />
** [[rest-brainstorming]]<br />
** - proposal<br />
** -microformat<br />
<br />
== See Also ==<br />
* [[forms-examples]]<br />
* [http://en.wikipedia.org/wiki/OpenSearch OpenSource search aggregation]<br />
* [http://simpletest.sourceforge.net/SimpleTest/tutorial_Browser.pkg.html PHP form filler]<br />
* [http://en.wikipedia.org/wiki/WSDL WSDL]<br />
* [http://en.wikipedia.org/wiki/Sitemap Sitemaps]<br />
<br />
<br />
* ''Normative references for tags used''</div>JasonKhttps://microformats.org/wiki/index.php?title=rest/examples&diff=12411rest/examples2007-01-10T14:46:44Z<p>JasonK: /* See Also */</p>
<hr />
<div>= XHTML-REST Examples =<br />
<br />
These are some examples of how people are currently implementing [http://en.wikipedia.org/wiki/Representational_State_Transfer#REST_versus_RPC REST] web services (usually in XML), to provide some context for how best to implement them in XHTML.<br />
<br />
== The Problem ==<br />
<br />
Quoting the wikipedia [http://en.wikipedia.org/wiki/Representational_State_Transfer#REST_versus_RPC REST] article:<br />
: In general, however, REST for data does not yet have a generally-accepted, standard format corresponding to HTML for documents, so each REST client must be custom-written to deal with XML at a fairly low level, and crawling XML data over REST is difficult (since it is not always easy to identify links). Proposals for a standard, generic format for use with REST based systems have included RDF, XTM, Atom, RSS (in its various flavours), and Plain Old XML (POX) with XLink to handle links<br />
<br />
In short, there isn't a clean design pattern for the optimal way to encode and use REST, which is precisely the sort of thing a microformats approach can provide.<br />
<br />
== Participants ==<br />
* [mailto:drernie@opendarwin.org Dr. Ernie Prabhakar]<br />
* [mailto:luke.arno@gmail.com Luke Arno]<br />
* [mailto:dimitri.glazkov@gmail.com Dimitri Glazkov]<br />
<br />
== Real-World Examples ==<br />
''Links to public web pages, either popular or insightful''<br />
<br />
=== [http://tools.ietf.org/wg/atompub/draft-ietf-atompub-protocol/ ATOM Publishing] ===<br />
Currently the best use of REST in a standard protocol.<br />
They're even discussing using XOXO!<br />
<br />
=== [http://images.amazon.com/images/G/media/i3d/01/associates/ecs-dg-20051005.pdf Amazon E-Commerce] ===<br />
<br />
Not a very good example, as they only have a single URI for the "REST" API, and do everything with url-encoding.<br />
<br />
=== [http://del.icio.us/doc/api Delicious API] ===<br />
<br />
Their so-called REST API is not, really. Here's a good critique which includes a more RESTful representation:<br />
<br />
http://www.peej.co.uk/articles/restfully-delicious<br />
<br />
== Existing Practices ==<br />
* ''Summary of common patterns discovered''<br />
* ''Other attempts to solve The Problem''<br />
== Proposal ==<br />
* Early drafts<br />
* ''Link to related pages as they become available''<br />
** [[rest-brainstorming]]<br />
** - proposal<br />
** -microformat<br />
<br />
== See Also ==<br />
* [[forms-examples]]<br />
* [http://en.wikipedia.org/wiki/OpenSearch OpenSource search aggregation]<br />
* [http://simpletest.sourceforge.net/SimpleTest/tutorial_Browser.pkg.html PHP form filler]<br />
* [http://en.wikipedia.org/wiki/WSDL WSDL]<br />
<br />
<br />
* ''Normative references for tags used''</div>JasonKhttps://microformats.org/wiki/index.php?title=User:JasonK&diff=32647User:JasonK2007-01-09T22:32:46Z<p>JasonK: Added some Wikipedia references for abbreviations</p>
<hr />
<div>At some point, I'll get around to starting some pages for discussing an API microformat and a logging microformat.<br />
<br />
[http://en.wikipedia.org/wiki/Sitemap Sitemaps] and [http://en.wikipedia.org/wiki/WSDL WSDL] may provide the foundation for an [http://en.wikipedia.org/wiki/Api API] microformat. I know that microformats shouldn't be invented where there isn't already something useful out in the wild that just needs a way to exist in xHTML. WSDL and sitemaps are examples of useful data that could be more useful if placed into a human ''and'' machine readable structure. Somewhat like [http://en.wikipedia.org/wiki/Doxygen Doxygen], this sort of microformat could be used with a site's [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] API documentation. Just as WSDL is useful for SOA application development, this microformat would be useful for applications using REST.<br />
<br />
The [http://rbach.priv.at/Microformats-IRC/2007-01-09 microformats IRC log] is already placed into a nice structure for filtering using JavaScript and CSS. Something similar should be provided for all logs and conversation histories. [http://en.wikipedia.org/wiki/Server_log Web server logs] are a good example and have some [http://www.w3.org/TR/WD-logfile standardization] already. That alone seems a bit too specific to me. Without broad enough consumer use, it wouldn't be suitable for a microformat. A general event history or time-line microformat, that includes event times, referral URLs, destination URLs, sizes, user agents, message text, warning/error/info priority/criticality categories, user/source references, action descriptions, and similar, would seem to be broadly usable.<br />
<br />
In the meantime, read my blog at [http://clamoring.blogspot.com Chaotic Clamoring]. I talk about microformats every now and again.</div>JasonKhttps://microformats.org/wiki/index.php?title=User:JasonK&diff=12378User:JasonK2007-01-09T22:30:09Z<p>JasonK: </p>
<hr />
<div>At some point, I'll get around to starting some pages for discussing an API microformat and a logging microformat.<br />
<br />
Sitemaps and WSDL may provide the foundation for an API microformat. I know that microformats shouldn't be invented where there isn't already something useful out in the wild that just needs a way to exist in xHTML. WSDL and sitemaps are examples of useful data that could be more useful if placed into a human ''and'' machine readable structure. Somewhat like Doxygen, this sort of microformat could be used with a site's REST API documentation. Just as WSDL is useful for SOA application development, this microformat would be useful for applications using REST.<br />
<br />
The [http://rbach.priv.at/Microformats-IRC/2007-01-09 microformats IRC log] is already placed into a nice structure for filtering using JavaScript and CSS. Something similar should be provided for all logs and conversation histories. [http://en.wikipedia.org/wiki/Server_log Web server logs] are a good example and have some [http://www.w3.org/TR/WD-logfile standardization] already. That alone seems a bit too specific to me. Without broad enough consumer use, it wouldn't be suitable for a microformat. A general event history or time-line microformat, that includes event times, referral URLs, destination URLs, sizes, user agents, message text, warning/error/info priority/criticality categories, user/source references, action descriptions, and similar, would seem to be broadly usable.<br />
<br />
In the meantime, read my blog at [http://clamoring.blogspot.com Chaotic Clamoring]. I talk about microformats every now and again.</div>JasonKhttps://microformats.org/wiki/index.php?title=irc-people&diff=12381irc-people2007-01-09T22:00:35Z<p>JasonK: Had an extra bracket in my name.</p>
<hr />
<div>A list of [[irc|IRC]] regulars sorted by nick and their normal timezones (winter/summer).<br />
<br />
* [[User:Adam Craven|AdamCraven]] (+0000)<br />
* [[User:Amette|amette]] (+1000)<br />
* [[User:Ashley|Ashley]] (+1000)<br />
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)<br />
* [[User:Ben Ward|BenWard]] (+0000)<br />
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)<br />
* [[User:HenriBergius|bergie]] (+0200/+0300)<br />
* [[User:BenWest|bewest]] (-0800/-0700)<br />
* [[User:Bob Jonkman|BobJonkman]] (-0500/-0400)<br />
* [[User:Boneill|boneill]] (+0000)<br />
* [[User:Brian|briansuda]] (+0000)<br />
* [[User:Cgriego|cgriego]] (-0600/-0500)<br />
* [[User:CharlesRoper|charles_r]] (0000/+0100)<br />
* [[User:Charlvn|Charl]] (+0200/+0200)<br />
* [[User:ChristopherStJohn|cks]] (-0600/-0500)<br />
* [[User:Cloud|Cloud]] (+0000)<br />
* [[User:Colin_Barrett|cbarrett]] (-1000)<br />
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)<br />
* [[User:Csarven|csarven]] (-0500/-0400)<br />
* [[User:Dan Kubb|dkubb]] (-0800/-0700)<br />
* [[User:DanC|DanC]] (-0600/-0500)<br />
** office hours: Wednesday afternoons, America/Chicago time<br />
* [[User:DannyAyers|danja]] (+0100/+0200)<br />
* [[User:Dave Cardwell|davecardwell]] (+0000)<br />
* [[User:DeanEro|deanero]] (-0800/-0700)<br />
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)<br />
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)<br />
* [[User:Ed Summers|edsu]] (-0500/-0400)<br />
* [[User:Enric|enric]] (-0800/-0700)<br />
* [[User:Enric|Enric]] (-0800/-0700)<br />
* [[User:Evan|evanpro]] (-0500)<br />
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)<br />
* [[User:Fil|Fil]] (+0200)<br />
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)<br />
* [[User:Grantbow|Grantbow]] (-0800/-0700)<br />
* [[User:Hlb|hlb]] (+0800-0700)<br />
* [[User:IanHickson|Hixie]] (-0800/-0700)<br />
* [[User:EdwardOConnor|hober]] (-0800/-0700)<br />
* [[User:IwaiMasaharu|iwaim]] (+0900)<br />
* [[User:Izo|IZO]]<br />
* [[User:JamieKnight|jammie_]] (+1000/0000)<br />
* [[User:Adactio|Jeremy Keith]] (+0000)<br />
* [[User:JasonK|jkridner]] (-0600/-0500)<br />
* [[User:JoeGregorio|jcgregorio]]<br />
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)<br />
* [[User:JulianStahnke|Julian Stahnke]] (+0000)<br />
* [[User:Kapowaz|kapowaz]] (+0000/+0100)<br />
* [[User:Keri Henare|kerihenare]] (+1200)<br />
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)<br />
* [[User:RyanKing|kingryan]] (-0800/-0700)<br />
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC<br />
* [[User:Lachlan Hunt|Lachy]] (+1000/+1100)<br />
* [[User:Mark Mansour|Mark Mansour]] (+1100)<br />
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)<br />
* [[User:CiaranMc|McNulty]] (+0000/+0100)<br />
* [[User:MikeKaply|mkaply]] (-0600/-0500)<br />
* [[User:SteveIvy|monkinetic/redmonk]] (-0700)<br />
* [[User:neuro|neuro`]]<br />
* [[User:NTollervey|ntoll]] (+0000/+0100)<br />
* [[User:Phae|Phae]] (+0000/+0100)<br />
* [[User:PriitLaes|plaes]] (+0200/+0300)<br />
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)<br />
* [[User:DavidOsolkowski|qid]] (-0500)<br />
* [[User:Remi|Remi]] (-0500/-0400)<br />
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)<br />
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)<br />
* [[User:Ronnos|Ron Kok]] (+0000)<br />
* [[User:Dana Benson|Snowden]] (-0800/-0700)<br />
* [[User:Smackman|Steve Farrell]] (-0800/-0700)<br />
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)<br />
* [[User:SuperPhly|SuperPhly]] (-600/-500)<br />
* [[User:Tantek|Tantek]] (-0800/-0700)<br />
* [[User:Trovster|trovster]] (-0800/-0700)<br />
* [[User:Tyler|Tyler Roehmholdt]] (-0800/-0700)<br />
* [[User:Vant|vant]] (+0900)<br />
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)<br />
* [[User:JacksonWilkinson|whafro]] (-0500/-0400)<br />
* [[User:Richard Conyard|WhiskeyM]] (+0000)<br />
* [[User:Veeliam|William Lawrence]] (-0800/-0700)<br />
* [[User:Ianloic|yakk]] (-0800/-0700)</div>JasonKhttps://microformats.org/wiki/index.php?title=rest/examples&diff=12410rest/examples2006-10-23T10:15:39Z<p>JasonK: /* [http://ietf.org/internet-drafts/draft-sayre-atompub-protocol-basic-03.txt ATOM Publishing] */</p>
<hr />
<div>= XHTML-REST Examples =<br />
<br />
These are some examples of how people are currently implementing [http://en.wikipedia.org/wiki/Representational_State_Transfer#REST_versus_RPC REST] web services (usually in XML), to provide some context for how best to implement them in XHTML.<br />
<br />
== The Problem ==<br />
<br />
Quoting the wikipedia [http://en.wikipedia.org/wiki/Representational_State_Transfer#REST_versus_RPC REST] article:<br />
: In general, however, REST for data does not yet have a generally-accepted, standard format corresponding to HTML for documents, so each REST client must be custom-written to deal with XML at a fairly low level, and crawling XML data over REST is difficult (since it is not always easy to identify links). Proposals for a standard, generic format for use with REST based systems have included RDF, XTM, Atom, RSS (in its various flavours), and Plain Old XML (POX) with XLink to handle links<br />
<br />
In short, there isn't a clean design pattern for the optimal way to encode and use REST, which is precisely the sort of thing a microformats approach can provide.<br />
<br />
== Participants ==<br />
* [mailto:drernie@opendarwin.org Dr. Ernie Prabhakar]<br />
* [mailto:luke.arno@gmail.com Luke Arno]<br />
* [mailto:dimitri.glazkov@gmail.com Dimitri Glazkov]<br />
<br />
== Real-World Examples ==<br />
''Links to public web pages, either popular or insightful''<br />
<br />
=== [http://tools.ietf.org/wg/atompub/draft-ietf-atompub-protocol/ ATOM Publishing] ===<br />
Currently the best use of REST in a standard protocol.<br />
They're even discussing using XOXO!<br />
<br />
=== [http://images.amazon.com/images/G/media/i3d/01/associates/ecs-dg-20051005.pdf Amazon E-Commerce] ===<br />
<br />
Not a very good example, as they only have a single URI for the "REST" API, and do everything with url-encoding.<br />
<br />
=== [http://del.icio.us/doc/api Delicious API] ===<br />
<br />
Their so-called REST API is not, really. Here's a good critique which includes a more RESTful representation:<br />
<br />
http://www.peej.co.uk/articles/restfully-delicious<br />
<br />
== Existing Practices ==<br />
* ''Summary of common patterns discovered''<br />
* ''Other attempts to solve The Problem''<br />
== Proposal ==<br />
* Early drafts<br />
* ''Link to related pages as they become available''<br />
** [[rest-brainstorming]]<br />
** - proposal<br />
** -microformat<br />
<br />
== See Also ==<br />
* [[forms-examples]]<br />
* [http://en.wikipedia.org/wiki/OpenSearch OpenSource search aggregation]<br />
* [http://simpletest.sourceforge.net/SimpleTest/tutorial_Browser.pkg.html PHP form filler]<br />
<br />
<br />
* ''Normative references for tags used''</div>JasonKhttps://microformats.org/wiki/index.php?title=irc&diff=9628irc2006-10-20T06:52:45Z<p>JasonK: /* People on irc */</p>
<hr />
<div>__NOTOC__<br />
= Microformats IRC =<br />
<br />
We have an IRC channel, [irc://irc.freenode.net/microformats #microformats on the freenode network].<br />
<br />
There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.<br />
<br />
== People on irc ==<br />
A list of IRC regulars and their normal timezones. (winter/summer)<br />
<br />
* [[User:BenWest|bewest]] (-0800/-0700)<br />
* [[User:Adam Craven|AdamCraven]] (+0000)<br />
* [[User:Amette|amette]] (+1000)<br />
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)<br />
* [[User:Ben Ward|BenWard]] (+0000)<br />
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)<br />
* [[User:Boneill|boneill]] (+0000)<br />
* [[User:Brian|briansuda]] (+0000)<br />
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)<br />
* [[User:Cgriego|cgriego]] (-0600/-0500)<br />
* [[User:CharlesRoper|charles_r]] (0000/+0100)<br />
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)<br />
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)<br />
* [[User:ChristopherStJohn|cks]] (-0600/-0500)<br />
* [[User:Cloud|Cloud]] (+0000)<br />
* [[User:DanC|DanC]] (-0600/-0500)<br />
** office hours: Wednesday afternoons, America/Chicago time<br />
* [[User:Dave Cardwell|davecardwell]] (+0000)<br />
* [[User:DeanEro|deanero]] (-0800/-0700)<br />
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)<br />
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)<br />
* [[User:EdwardOConnor|hober]] (-0800/-0700)<br />
* [[User:Enric|enric]] (-0800/-0700)<br />
* [[User:Evan|evanpro]] (-0500)<br />
* [[User:Fil|Fil]] (+0200)<br />
* [[User:Grantbow|Grantbow]] (-0800/-0700)<br />
* [[User:Hlb|hlb]] (+0800-0700)<br />
* [[User:IanHickson|Hixie]] (-0800/-0700)<br />
* [[User:Izo|IZO]]<br />
* [[User:JoeGregorio|jcgregorio]]<br />
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)<br />
* [[User:JasonK|jkridner]]] (-0600/-0500)<br />
* [[User:Keri Henare|kerihenare]] (+1200)<br />
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)<br />
* [[User:Mark Mansour|Mark Mansour]] (+1100)<br />
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)<br />
* [[User:neuro|neuro`]]<br />
* [[User:Phae|Phae]] (+0000/+0100)<br />
* [[User:PriitLaes|plaes]] (+0200/+0300)<br />
* [[User:DavidOsolkowski|qid]] (-0500)<br />
* [[User:Remi|Remi]] (-0500/-0400)<br />
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)<br />
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)<br />
* [[User:RyanKing|kingryan]] (-0800/-0700)<br />
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC<br />
* [[User:Csarven|csarven]] (-0500/-0400)<br />
* [[User:Dana Benson|Snowden]] (-0800/-0700)<br />
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)<br />
* [[User:Tantek|Tantek]] (-0800/-0700)<br />
* [[User:Trovster|trovster]] (-0800/-0700)<br />
* [[User:Dan Kubb|dkubb]] (-0800/-0700)<br />
* [[User:Ed Summers|edsu]] (-0500/-0400)<br />
* [[User:Smackman|Steve Farrell]] (-0800/-0700)<br />
* [[User:Enric|Enric]] (-0800/-0700)<br />
* [[User:Charlvn|Charl]] (+0200/+0200)<br />
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)<br />
* [[User:Vant|vant]] (+0900)<br />
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)<br />
* [[User:IwaiMasaharu|iwaim]] (+0900)<br />
* [[User:Richard Conyard|WhiskeyM]] (+0000)<br />
* [[User:Veeliam|William Lawrence]] (-0800/-0700)<br />
* [[User:Ianloic|yakk]] (-0800/-0700)<br />
* [[User:Ashley|Ashley]] (+1000)<br />
<br />
<br />
=== Greetings ===<br />
<br />
To display a brief description of who you are each time you join the channel, you can create a definition for your username. To do so pass the <tt>?def</tt> command using something like the following convention (be brief):<br />
<br />
<code>?def jdoe is John Doe and can be found online at <nowiki>http://www.example.com</nowiki></code><br />
<br />
More information about using JiBot commands can be found on the [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot website]<br />
<br />
=== bots ===<br />
<br />
* [[mfbot]]<br />
* [[mflogbot]]<br />
* [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot]<br />
<br />
== Logs ==<br />
<br />
Available here: http://rbach.priv.at/Microformats-IRC/<br />
<br />
Atom feed of logs available here: http://microformat.makedatamakesense.com/log_feed/<br />
<br />
== IRC meetups ==<br />
<br />
The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.</div>JasonK