If you have an idea or suggestion that doesn't seem to fit well on any other page, please put it here.
If you see an idea or suggestion here and know of a good place for it, please move.
When a spec is finalized, I would like to see the documentation in a similar format to PHP.net documentation (example). Each page of the PHP.net documentation features the official content, with heavily moderated comments below. Often, these comments tell you eveything you need to know (key bugs, common questions, best practices, common uses). It's the equivalent of asking a developer for help with a function: (s)he'll tell you how it works, then give you a couple of quick indispensible tips.
How about a standard way to denote in an HTML page that one or more XML versions (Echo, RSS, etc) are available?
[GuilleBe] This could be Autodiscovery.
[AsbjornUlsberg, RefactorOk] It can also be done through <link>-elements in <head>; <link rel="echo-feed" href="feed.xml" />.
[DaveMeehan] Should Echo support subscriptions to entries. Many blogs allow readers to subscribe to notifications about changes to specific entries, for example when new comments are left. Or is this to be functionality supported in an echo client to allow readers to follow updates?
[AdamRice] Can you give an example of a mechanism by which this might work? I don't see it myself. I can certainly imagine, say, a PHP-generated feed where the feed name embodies the requested content--some people are already doing this in RSS--but I don't see how to roll this into the !Echo syntax without getting hugely complicated.
[JeremyGray] This could be added quite simply via a post-1.0 extension module, likely providing entry with an additional element or attribute containing an URL pointing to a feed for updates to the entry. Comment feeds could be addressed through the same URL if one were so inclined, but likely separately via an URL provided in some other element or attribute. Sounds quite doable to me, but as a SuggestionBox item it can and probably should sit on the shelf until post-1.0 (IMHO).
[DaveMeehan] For sites that support subscription, they would include an element in the entry that provides a URL that takes an email address (or possibly a pingable resource) that the content creator can send a notification on changes to the entry. You might need a similar element in the feed element, so that new entries can be notified. This may be against the spirit of Echo, which really is a pull process, but this method allows sites to implement push notification once subscribed.
[AsbjornUlsberg] I think subscriptions should be supported. On a subscription-oriented site, the feeds can be PUSHed to subscribers when entries are updated, instead of PULLed at specific (and most certainly too often) intervals. Both PUSH and PULL should be supported, but I believe that the PUSH method should be recommended as it will decrease serverload and bandwith usage, and it will also give the author more control over when an entry is updated, not only on the originating site, but on all sites on which the entry occurs. Subscriptions should be discussed thoroughly, imho.
Is there a way of optionally specifying the MIME type of linked to resources. This could be useful if the source server isn't doing anything intelligent with it, just sending it out as text/html or text/xml when instead it could be application/atom+xml. This could be useful to guide a news reader agent to offer to subscribe to that linked resource, rather than simply handing it off to a web browser.
I have in mind a scenario that goes a bit like this: I have a blog, it has postings, postings can have comments. I have an atom feed for the postings on the blog. I do have seperate feeds for each posting's comments, even though they all start out as empty. I also have an atom feed for most recent comments across all postings. This feed might have multiple entries for the same posting, being multiple comments on that posting.
I could also have a feed that represents all these seperate comments feeds, where the links in this "virtual" blog point to the respective atom feeds, rather than some web page. There would only be one entry per posting, as multiple comments are represented within the one linked feed. (There wouldn't be a permalink for the psuedo-posting that says "the comments feed for post#123 has changed", but that's a different problem).
With that set up one could then subscribe to the main blog feed to watch what gets posted, and then when they read a post they want to follow the comments on they could subscribe to that post's comment feed, and they could also subscribe to the feed which would alert to the reader to an older posting getting comments.
If all this happens without relying on (a) the server being smart enough to send along the appropriate mime type, and (b) the web browser being smart enough to hand off the served result (if it has the appropriate mime type) to the news reader; then that would be a good thing.
[JakobVoss] Has anybody had a look at the OpenArchivesInitiative and the OAI Protocol for MetadataHarvesting? (see http://www.openarchives.org/OAI/openarchivesprotocol.html) If there is an XML schema for Weblog entries you can also use this protocoll for distributing them.
[NicholasChase] "Maybe I should stick my nose in and suggest a way to specify the location of an XSLT stylesheet at the top of the feed, so we don't have to do this again in another five years." (Copied from [ "An Outsider's View of the RSS Controversy"]). 2003-07-15
[DaveP ] nEcho processing. Having looked at a couple of plain 'diary' style blogs, it struck me that there are or should be various processing models. E.g. to keep only the most recent 5 entries when processing through to XHTML for viewing. There is a tools page, but no processing page, where I could expand on this? E.g. submit stylesheets.
If you can't find a page that covers a topic you want to discuss, find one or a few that come close, edit them and add a "See also" or a brief remark describing what the new topic covers, then "link" to the new page by using capitalized words, like SuggestionBox.
It's best to link to "files", like stylesheets, back at your own site from the wiki, rather that posting them in their entirety.
Small point, MoinMoin doesnt work on IE for the Mac, can't edit
clarification: pages with more than 32K of wikitext can't be edited by IE/Mac... it loads the edit box with the first 32K, and doesn't let you add more unless you first delete some. Lots of nasty truncations can occur.