forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avik Sengupta <a...@apache.org>
Subject Re: Forrest TODO list
Date Thu, 02 Jan 2003 07:05:28 GMT
> It's possible currently with custom transformers and lots of manual
> sitemap hacking.  I can't see how we could make this user-friendly.
Detailed documentation perhaps? My view is, i am certainly willing to
spend some time doing this, but certainly dont want to sit  and figure
out the whole of cocoon. In general my thinking is, at this stage in
forrest, more documentation will get more users. 

> Users don't rant, they quietly leave :)
Never heard a truer word said. True of most of the service industry,
actually!

On Thu, 2003-01-02 at 12:05, Jeff Turner wrote:
> On Wed, Jan 01, 2003 at 09:26:17PM +0100, Marc Portier wrote:
> > 
> > 
> > Jeff Turner wrote:
> > >Hi,
> > >
> > >Hope you all had a good break.
> > >
> > 
> > yep & thx, before wishing forrest and all around a breakthrough 
> > in 2003 I'ld also like to thank this group for the work all of 
> > you havve been setting aside here and you Jeff, personally, for 
> > the way you have been active in this project the past months... 
> > quite some 'acorns' you've been dropping around :-)
> 
> :) Thanks.  Though I suspect in the long term, one person gleefully
> chasing rabbits down holes isn't going to do much good.  Hence this
> attempt at structuring the work..
> 
> ...
> > - yep, in the same region (mid-term) would be some stylesheet 
> > (maybe together with some inputmodules stuff and config-file for 
> > the extra data) that allows publishing the status.xml as a 
> > rss.xml that people can aggregate in their blog-rolls (recent 
> > thought, people with experience or good pointers, throw them on 
> > the list please)
> 
> It's all there, just commented out until there is a sensible way to add
> the 'extra data', specifically the project name and description.  If you
> don't mind hardcoding project details in changes2rss.xsl, it should work
> today.
> 
> > - also the edit-side of docs could use 'something' (really vague, 
> > I know, so put it on long term unless somebody can write down 
> > some sensible use cases)
> 
> A simple "edit this page's XML" button, where edited content gets mailed
> to a list, would be fine for me.
> 
> > - more nearby (mid-term?) something that makes the various 
> > book.xml's less of a hastle (and maybe settles down if libre is 
> > ever going to get somewhere or not)
> 
> Already in the LINKMAP_BRANCH, book.xml's are generated dynamically from
> site.xml.  I'd imagine site.xml (or it's RDF-based successor) could be
> generated by Libre.  Would be a shame to waste all that code..
> 
> > - equally closer by I've sensed some emerging need for decoupling 
> >  the 1-1 between html and pdf (as printable version) typically 
> > people would like to aggregate some xdocs into one pdf (or 
> > straight print-nice html in fact) and/or split up a bigger 
> > document into multiple next|previous pages (given the fact that 
> > some were recently making the pdf for outside vs. html for 
> > interal distribution remark)
> 
> It's possible currently with custom transformers and lots of manual
> sitemap hacking.  I can't see how we could make this user-friendly.
> 
> Seems we have two long-term routes for meeting this sort of 'advanced'
> use-case:
> 
> 1) Make the sitemap user-friendly, and do our best to educate people how
> to set up custom sitemaps for this sort of thing.  Beyond a certain level
> of complexity, the user has to get involved.
> 
> Problem here is that, as we try to add new features to meet common
> requests, we also complicate the sitemap, making it harder for users to
> customize.
> 
> 2) We try to internalise and hide the sitemap.  We could have an
> arbitrarily fancy GUI interface, and dynamically generate a Sitemap
> object, containing exactly the components and features the user needs.  
> 
> 
> This problem of growing sitemap complexity has a parallel with Ant script
> complexity.  We need a sitemap equivalent of Maven or Centipede.  Maybe
> Cocoon blocks will be the answer.
> 
> > - on the forrestbot management web-gui: might be interesting to 
> > also be able to register new skins on there, and maybe web-form 
> > like submit or even edit a bot-config to add in the list.
> 
> We also need a RNG schema for the forrestbot.
> 
> > as for the forrest-users mailing list: my feeling would be that 
> > committers still need to be subscribed to both anyway (and I'm 
> > lazy :-p ), so I would leave it to non-committers to actually 
> > raise the need (I mean when they start complaining about wasted 
> > bandwith on for them non-relevant stuff then it is probably a 
> > better time/argument than the 'we want to rant and flame in a 
> > more private corner' :-))
> 
> Users don't rant, they quietly leave :)
> 
> 
> --Jeff
> 
> > regards,
> > -marc=




Mime
View raw message