sfwiki-devel

Re: [sfWiki-devel] release 2 beta

[Todd L. M. <tm...@ha...>]

> Also auto linking doesn't seem to be working properly:

	You know what I forgot to test?  Calling sfWikiFormat with a
complex page.  I'm using echo to pipe the page text into sfWikiFormat from
the .php3 script, so embedded newlines (and possibly embedded "'"s) wreak
terrible havoc.  I'll have to think about this one for a while.

-jQuinn

Re: [sfWiki-devel] release 2 beta

[Iain S. <iai...@ya...>]

At 09:19 PM 9/11/00 -0400, Todd L. Miller wrote:
>         Is now formatted at sfwiki.sourceforge.net/sfWiki/, so please try
>to find bugs in it for me -- I've made several code changes in the course
>of the installation that I'll merge back into CVS for the 'official'
>release when this trial period is over.  I also wrote a script to import
>files for the header and footer, since they can no longer be edited with
>the Wiki -- to reduce the risk of malicious PHP.

Hey, its looking good.

Bugs,

Well, the formatting pages (footer and header) still appear in the 
automatic listing (hubs/nodes etc).  Clicking on them gets you to a 
completely blank page.  i would suggest removing them from the listings 
rather than fixing what happens when you try and navigate to that page.

Also auto linking doesn't seem to be working properly:

http://sfwiki.sourceforge.net/sfWiki/view.php3?topic=MainWebHome

See the several links that should be linked and aren't.  I'm also not sure 
how much wiki markups are supported but none of them rendered on that page.

The edit button also appears to be missing for pages.  Is this 
intentional?  Otherwise, the only way I could find to "legitimately" edit a 
page was to create a new one.

Well, I guess that's enough for now.  :) he he he.  For once, its I who 
gets to report bugs and someone else fixes them!  yes!  Actually, if you 
need help, let me know.

-iain

[sfWiki-devel] release 2 beta

[Todd L. M. <tm...@ha...>]

	Is now formatted at sfwiki.sourceforge.net/sfWiki/, so please try
to find bugs in it for me -- I've made several code changes in the course
of the installation that I'll merge back into CVS for the 'official'
release when this trial period is over.  I also wrote a script to import
files for the header and footer, since they can no longer be edited with
the Wiki -- to reduce the risk of malicious PHP.

-jQuinn

Re: [sfWiki-devel] status report

[Todd L. M. <tm...@ha...>]

> Complex formatting and 'html tricks' really don't have much of a place in
> a wiki.  If you could come up with a logical, simple wiki markup for
> images and linking (where the display text is not the same as the link and
> for same page anchors) I'd say to completely eliminate html.

	I'll work on this.  It could make things easier for me anyway. :)

> Of course, since its already implemented, I guess I'd leave it in.  :)

	I did decide to move over to a flex/bison approach for doing the
WikiMarkup, mostly because I find nested formatting more intuitive than
the alternative.  I hope to finish hammering out the last of the conflicts
(or proving them harmless) today, which ought to finish the formatting for
release 2.  I have the info.php3 stuff partially implemented in a
different codebase, but I'm not sure if I'll get to it; I am trying to
write an operating system, you know :)

-_Quinn

Re: [sfWiki-devel] status report

[Iain S. <iai...@ya...>]

--- "Todd L. Miller" <tm...@ha...> wrote:
> > I think you should approach this in the opposite direction.
> 
> 	I wanted to support HTML in the Wiki because it's going to be
> easier for some people to write the HTML than learn the
> WikiMarkup.  TWiki says it supports 'most' HTML tags, though I didn't
> find a full list.

Agreed.  But it opens up security holes (especially on a php powered
site).

> > Ideally, wiki markups and no html should be use.  Realistically,
> > wiki markups and some limited set of html will be needed.
> 
> 	Actually, we could almost certainly get away with no HTML markup
> at all; there's nothing intrinsically difficult about it.  It's just
> that
> past a certain point, certain features make more sense in HTML, because
> they're advanced enough that the author is likely to know the HTML to
> create them.  However, I suspect that most of these features are
> potential
> security holes :)

Yup.  The wiki is collaborative first.  Hence the simple wiki markups and
simple text (wiki markups should look a lot like ascii formatting).  IMHO,
you should always sacrifice features for ease of use, speed, and
communication when dealing with a wiki.  The wiki is all about content. 
Complex formatting and 'html tricks' really don't have much of a place in
a wiki.  If you could come up with a logical, simple wiki markup for
images and linking (where the display text is not the same as the link and
for same page anchors) I'd say to completely eliminate html.

> 	I'll give it some more thought, but before I do -- I allowed
> nesting of bold/italic/fixed-font, which it doesn't look like the normal
> wiki does.  There a reason for that?

Yup.  The way it does its parsing.  The original perl wiki code is a bunch
of regex with very simple substitution rules.  As such, its not a full
blown parser, and can't handle some markups well without a lot of painful
contortions.  Once again, simplicity ruled (although perhaps for speed of
implementation rather than as a design goal) so nesting is simply not
supported.  I'd probably avoid supporting nesting simply because it can
possibly have unintended consequences...  Of course, since its already
implemented, I guess I'd leave it in.  :)

Note: I know I don't say it often enough, but I really do appreciate the
time you're putting into this.

-iain

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

Re: [sfWiki-devel] status report

[Todd L. M. <tm...@ha...>]

> I think you should approach this in the opposite direction.

	I wanted to support HTML in the Wiki because it's going to be
easier for some people to write the HTML than learn the
WikiMarkup.  TWiki says it supports 'most' HTML tags, though I didn't
find a full list.

> Ideally, wiki markups and no html should be use.  Realistically,
> wiki markups and some limited set of html will be needed.

	Actually, we could almost certainly get away with no HTML markup
at all; there's nothing intrinsically difficult about it.  It's just that
past a certain point, certain features make more sense in HTML, because
they're advanced enough that the author is likely to know the HTML to
create them.  However, I suspect that most of these features are potential
security holes :)


	I'll give it some more thought, but before I do -- I allowed
nesting of bold/italic/fixed-font, which it doesn't look like the normal
wiki does.  There a reason for that?

-_Quinn

Re: [sfWiki-devel] status report

[Iain S. <iai...@ya...>]

--- "Todd L. Miller" <tm...@ha...> wrote:
> release two out the door.  I hope to get quite a bit of work done on
> this
> holiday weekend, possibly finishing it, if things go well.

Very cool.

> 	One of the things I want to put in is HTML filtering for the
> WikiPages.  My question -- what tags, aside from <script>, shouldn't be
> allowed?

I think you should approach this in the opposite direction.
Ask, "what tags should be allowed".  Start with a small
subset of 'essential' html and try and keep the list as
absolutely small as possible.  For every html tag you allow,
you should be thinking, what simple wiki markup could be
used to replace it.

Ideally, wiki markups and no html should be use.  Realistically,
wiki markups and some limited set of html will be needed.

Off the top of my head, i'd allow the anchor and image tags.
All the other essential ones (including tables) are supported
with current wiki markups.  When authors request more, we can
check if there is an existing wiki markup, if one can be created,
or if we must use html.

That's my opinion.  I could be wrong.

-iain

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

[sfWiki-devel] status report

[Todd L. M. <tm...@ha...>]

	The SourceForge project server broke sfWiki about ten days ago, so
until now, I hadn't been able to get any work done, trying to figure out
what went wrong.  At any rate, because I rather thoroughly trashed the
sfWiki and JOS sites doing this, I've pulled them down until I can push
release two out the door.  I hope to get quite a bit of work done on this
holiday weekend, possibly finishing it, if things go well.

	One of the things I want to put in is HTML filtering for the
WikiPages.  My question -- what tags, aside from <script>, shouldn't be
allowed?

-jQuinn

Re: [sfWiki-devel] integration opportunity?

[Iain S. <iai...@ya...>]

On 10 Jun 00, at 17:33, Todd L. Miller wrote:

> 	Just realized, while doing some work on SF for another project,
> that not only would SF benefit from applying WikiFormatting to the 'whole
> site' (e.g. the output for every 'text only input' should be
> WikiFormatted), but that the integration could go the other way.  The
> example that struck me was automating links to tasks, but it would work
> for links to forums, etc, as well.

You're definitely right.  If you isolate the renderer and link "checker" 
well, I bet the SF people would be interested in possibly using it as 
a markup for tons of their other services.  I have used WikiRenderer 
separate from the Wiki for several little web things where I just 
wanted a fast, text only way of simply marking up text for the web.

-iain

[sfWiki-devel] integration opportunity?

[Todd L. M. <tm...@ha...>]

	Just realized, while doing some work on SF for another project,
that not only would SF benefit from applying WikiFormatting to the 'whole
site' (e.g. the output for every 'text only input' should be
WikiFormatted), but that the integration could go the other way.  The
example that struck me was automating links to tasks, but it would work
for links to forums, etc, as well.

-_Quinn

[sfWiki-devel] rescheduled release 2

[Todd L. M. <tm...@ha...>]

	I didn't get any work done on sfWiki this week, unfortunately, so
I've moved the release 2 date back a week, to June 18.

-_Quinn

[sfWiki-devel] Re: WikiWeb [was Re: How does JavaSpaces actually work?]

[Iain S. <iai...@ya...>]

On 2 Jun 00, at 21:40, Cees de Groot wrote:

> Reader "A":
> >  BTW, your JiniWiki site kicks ass -- I'll be hoping to contribute =
> >soon.
> 
> Reader "B":
> >Arrrggghhh! The WikiWikiWeb site drives me nuts.

Actually, that's the same reader!

> So we may safely conclude that some like it, and some don't :-)

And most are conflicted about it!

> Actually, there's nothing in Wiki that /forbids/ a bid of structure. On the C2

Agreed.  The freeform nature of the wiki is both its power and its 
curse.  It's wonderful to just throw information into the wiki, and 
then to just sort of do a Zen-like excursion back through it. You 
stumble across the most interesting things in a big wiki.  On the 
otherhand, when you know what you're looking for (or at least have 
a really good idea of what you want), its often really hard to find it 
in the wiki.  Sorta like how you remember the the name of the band 
that sang that song 2 days after you needed the info while taking a 
shower.

Actually, we've [1] been playing around with some self-forming 
structure ideas for the wiki lately.  Our basic idea right now being 
that with these "random" webs of linked pages, there are going to 
be natural data 'centers' and link 'hubs'.  

Centers are pages that many other pages link to.  The more pages 
that link to the page, the more 'valuable' and 'centered' that page is 
in the web.  It's basically the most valuable resources in the web 
by virtue of the number of references to it.  Automatically identifying 
and listing important wiki centers will probably 'float' the important 
documents up where you can easily see them.

hubs are pages that have a lot of links to other pages.  they act as 
directories and form something similar to a table of contents for the 
wiki. once again, by having the wiki itself automatically identify, 
and list the top 20 hub pages we hope to provide more structure for 
wiki reading and editing without taking away from its freeform 
nature.

Comments are suggestions are greatly welcome (although this is 
getting off topic for the jini-users list).  I suggest moving it to the 
sfwiki developers mailing list:  sfw...@li...
which you can join at sourceforge.net (see url at bottom of email).

-iain

[1]
<digression> 
I was sort of the wiki clone librarian for a while.  Markus ?Peter? 
(not sure of the last name) wrote a perl clone (JOSWiki) of the C2 
Wiki for the JOS project (free java os www.jos.org).  He then went 
on to do other things, and I came on board as the JOS webmaster 
and inherited the code (minor patches aside I didn't do much with 
it).  Sometime shortly after, Peter Thoeny of takefive.com, grabbed 
the JosWiki source, improved it for his company intranet and 
customer knowledge base, then released it as TWiki.  I took the 
new TWiki and used it to replace the old JosWiki.  But the perl 
really frustrated me (performance was poor and leaked errors) so I 
ported it to PHP (PWiki), the user authentication never got done 
though and so JOS still runs TWiki.  Then Todd Miller (a JOS 
member) came along, ported (well actually mostly looked at my 
source then rewrote it) my PWiki to use a MySql database, and is 
integrating it to work with SourceForge (www.sourceforge.net). It's 
called sfWiki and is still under construction.  You can help out with 
the new project:

https://sourceforge.net/project/?group_id=5181

</digression>

Re: [sfWiki-devel] release plan

[Iain S. <iai...@ya...>]

On 30 May 00, at 18:48, Todd L. Miller wrote:

> 	Yup.  The documentation is in dire need of work.  Maybe you/we
> should get root for Clark's box and record the administator/deployer side
> of things.  (Once I've done something, it becomes very difficult to make
> sure I record /everything/ I'm doing the second, especially if I forgot to
> reset something.)  I'll write the programmer's guide, and we can leave the
> user's guide up in the air for now.

Sounds like a plan.  I'm hoping to have some time to setup a linux 
box at home and I could easily document the process of installing 
things.  Of course, I can't see that happening for at least a few 
weeks so if it comes up as the 'next thing to do' and I'm not ready, 
we should probably just use someone else's box.

> > And now that we have a 'safe' wiki, another major documentation
> > effort.
> 
> 	Indeed.  Perhaps I should add to the file-release reorganization,
> include documentation package(s).  (Add a 'documentation' task list?)

Yes.  I agree.  I can imagine people wanting to download the 
documentation set without the wiki source (they need to access, 
maintain, program an existing sfwiki installation...)

> 	This is good.  You've noted before that most wiki's eventually
> become rather static.  (And I imagine for those with slow links, d/l'ing a
> tarball over lunch break will be a more satisfying way of browsing
> anyway.)

Yup.  Plus, if you have something like JOS's 'technical 
distributions' its nice to include a browsable snapshot of the wiki 
which basically is the documentation for the project.

-iain

Re: [sfWiki-devel] release plan

[Todd L. M. <tm...@ha...>]

> I might suggest a more structured and thorough documentation set 
> (programmer, administrator/deployer and user) may be a good idea 
> at this point.  Since this release would make the sfwiki a fully 
> functional (but not 'safe') wiki system.

	Yup.  The documentation is in dire need of work.  Maybe you/we
should get root for Clark's box and record the administator/deployer side
of things.  (Once I've done something, it becomes very difficult to make
sure I record /everything/ I'm doing the second, especially if I forgot to
reset something.)  I'll write the programmer's guide, and we can leave the
user's guide up in the air for now.

> And now that we have a 'safe' wiki, another major documentation
> effort.

	Indeed.  Perhaps I should add to the file-release reorganization,
include documentation package(s).  (Add a 'documentation' task list?)

> I might add that at some point around release 5 (most major 
> important features implemented) the project should probably do a 
> code review and possibly a full rewrite/rearchitect.

	This is a very good idea.  I imagine a lot of this will be done
for the user auth / session management, because it will (probably) touch
most of the code, but a second look can never hurt.

> Snap shot (full html 'offline' site snapshot of a wiki's contents).  this 
> allows someone to put together a cd of a wiki that someone can 
> browse.

	This is good.  You've noted before that most wiki's eventually
become rather static.  (And I imagine for those with slow links, d/l'ing a
tarball over lunch break will be a more satisfying way of browsing
anyway.)

> auto archive (some facility of creating a data 'bundle' that can be 
> used to archive and restore a wiki.  this may be as simple as doing 
> a database table dump and targzipping the results).

	Should include the *.ihtml formatting stuff, as well, but this is
another good idea.

-_Quinn

Re: [sfWiki-devel] release plan

[Iain S. C. M. <crr...@me...>]

On 28 May 00, at 16:26, Todd L. Miller wrote:

> Release 2: [provisionally, by June 11]
> * spend some time cleaning up (refactoring?) the code.
> * implement statistics as previously discussed
> * implement (the rest of) WikiFormatting
> - Change the file release scheme.
> 	one module for -full, with .tgz and .zip
> 	one module for -htdocs, -portal, -root, with .tgz and .zip

I might suggest a more structured and thorough documentation set 
(programmer, administrator/deployer and user) may be a good idea 
at this point.  Since this release would make the sfwiki a fully 
functional (but not 'safe') wiki system.

> Release 3:
> * version tracking
> 
> Release 4:
> * user authentication and session management

And now that we have a 'safe' wiki, another major documentation 
effort.

> Release 5:
> * page watches
> * page deleting
> * CVS ACLs (, integration w/)
> 
> Comments?  (What do we do past Release 5?)

Looks good.  Seems like a good schedule to me.

I might add that at some point around release 5 (most major 
important features implemented) the project should probably do a 
code review and possibly a full rewrite/rearchitect.  I find it always 
good to have a point where you say, 'ok, now lets look this thing 
over and from what we learned, let's rewrite it better/faster/etc' or 
you might look at it and say, 'hey, this thing doesn't need a rewrite'.

Other features not listed that I think would be really nice:

Snap shot (full html 'offline' site snapshot of a wiki's contents).  this 
allows someone to put together a cd of a wiki that someone can 
browse.

auto archive (some facility of creating a data 'bundle' that can be 
used to archive and restore a wiki.  this may be as simple as doing 
a database table dump and targzipping the results).

-iain

[sfWiki-devel] release plan

[Todd L. M. <tm...@ha...>]

Release 2: [provisionally, by June 11]
* spend some time cleaning up (refactoring?) the code.
* implement statistics as previously discussed
* implement (the rest of) WikiFormatting
- Change the file release scheme.
	one module for -full, with .tgz and .zip
	one module for -htdocs, -portal, -root, with .tgz and .zip

Release 3:
* version tracking

Release 4:
* user authentication and session management

Release 5:
* page watches
* page deleting
* CVS ACLs (, integration w/)

Comments?  (What do we do past Release 5?)

-jQuinn

Re: [sfWiki-devel] php 4.0.0 available

[Todd L. M. <tm...@ha...>]

> Where did you see this announcement?  

	Slashdot. :)

-_Quinn

Re: [sfWiki-devel] info.php3

[Iain S. C. M. <cr...@me...>]

On 23 May 00, at 0:34, Todd L. Miller wrote:

> > Yes it should.  I think it should be easy (at least in my 
> > implementation it turned out pretty simple).  
> 
> 	Because you can just append the current topic to the links-to-me
> field of every topic in the links-from-me field.  (duh!) Maintaining
> uniqueness will be annoying to do programatically; I'll investigate
> possibilities for using facilities in MySQL.  (Could be done in PHP by
> using associative arrays, but they're probably rather expensive to
> generate.  Since linksto/from aren't fields that will need to be edited by
> hand if something terrible happens (and/or restored from backup), it may
> be worth looking into storing the associative array of each field in
> binary...)

Having not seen the code of how this is done I can't really 
comment.  I was under the impression this was being done in a 
separate table though...

> > > *: It would be interesting to write a WikiFormatter for emails :) **:
> > 
> > Definitely.  And for java and php source code....
> 
> 	Hey, now /that's/ a good idea.  It shouldn't be too hard to do,
> either... and it would /really/ nice to add it as an option to the CVSweb
> for SF :)

Yup.  CVSWeb should be rewritten in php anyhow.... another 
project.  :)

> > Agreed.  Athough, at least with our JOS wiki, it will probably be ...
> 
> 	Remind me, once I get the global page working, to cache it -- if
> something hasn't changed since the last cron-job, just don't bother with
> it.

OK.  If possible though, I'd try and design the sfwiki so that it 
doesn't require cron jobs to maintain.  This will help ease 
installation and portability.  otherwise, you have to assume cron 
availability and access for everyone (possible on sourceforge sites, 
but not on others).  Instead, use the page edits as an 'event' that 
can trigger big cleanup/rebuild/maintenance tasks.  They're rare 
enough that they can act as cron-ish jobs and not really affect site 
performance.  And people doing page edits probably won't notice or 
mind an extra second or delay in the edit save process.

-iain

Re: [sfWiki-devel] php 4.0.0 available

[Iain S. <iai...@ya...>]

Where did you see this announcement?  

On 23 May 00, at 0:02, Todd L. Miller wrote:

> 	What, if anything, does this mean for sfWiki?  (Will SF upgrade
> and give us session(/user?) management for free?)

As far as sourceforge user stuff, we have to wait until sourceforge 
gives us access and instructions.  PHP4 authentication and 
session stuff will definitely make this easier, but since sourceforge 
was built on php3 i doubt they're using the php4 built in features. 
Maybe they'll port over and then expose it to us.  In the meantime, 
i think we might as well implement our own with the intentional 
design of making it easy to plug into the sourceforge authentication 
when its made available.  From my general impressions, allowing 
the sourceforge websites to access sourceforge authentication info 
is hard to design securely and not that high a priority so may take 
a long time...

-iain

Re: [sfWiki-devel] integration with SF code?

[Iain S. <iai...@ya...>]

On 23 May 00, at 0:35, Todd L. Miller wrote:

> 	I'd been looking at if from the perspective of having to download
> the whole SF site source to get sfWiki to work, but we should be able to
> code around that.

Yeah.  I like the integration with Sourceforge but sfwiki will really 
have a lot more value if it can be installed and run stand-alone with 
reasonable ease.

-iain

Re: [sfWiki-devel] info.php3

[Todd L. M. <tm...@ha...>]

> Yes it should.  I think it should be easy (at least in my 
> implementation it turned out pretty simple).  

	Because you can just append the current topic to the links-to-me
field of every topic in the links-from-me field.  (duh!) Maintaining
uniqueness will be annoying to do programatically; I'll investigate
possibilities for using facilities in MySQL.  (Could be done in PHP by
using associative arrays, but they're probably rather expensive to
generate.  Since linksto/from aren't fields that will need to be edited by
hand if something terrible happens (and/or restored from backup), it may
be worth looking into storing the associative array of each field in
binary...)

> As far as contention, i'd ignore it.

	OK.  If you're not going to worry about it, I won't either :)

> > *: It would be interesting to write a WikiFormatter for emails :) **:
> 
> Definitely.  And for java and php source code....

	Hey, now /that's/ a good idea.  It shouldn't be too hard to do,
either... and it would /really/ nice to add it as an option to the CVSweb
for SF :)

> Agreed.  Athough, at least with our JOS wiki, it will probably be ...

	Remind me, once I get the global page working, to cache it -- if
something hasn't changed since the last cron-job, just don't bother with
it.

-_Quinn

Re: [sfWiki-devel] integration with SF code?

[Todd L. M. <tm...@ha...>]

> Since we are calling it sourceforge wiki, i don't see why we 
> shouldn't integrate it tightly with sourceforge.  If its done right (with 
> a well named, and well designed api), it should be easy for users 
> that don't want to use sourceforge to rewrite or disable sourceforge 
> specific features.

	I'd been looking at if from the perspective of having to download
the whole SF site source to get sfWiki to work, but we should be able to
code around that.

-_Quinn

[sfWiki-devel] php 4.0.0 available

[Todd L. M. <tm...@ha...>]

	What, if anything, does this mean for sfWiki?  (Will SF upgrade
and give us session(/user?) management for free?)

-_Quinn

Re: [sfWiki-devel] info.php3

[Iain S. C. M. <cr...@me...>]

On 20 May 00, at 15:00, Todd L. Miller wrote:

> 	Should saving a WikiTopic* update all pages links-to-me field?  

Yes it should.  I think it should be easy (at least in my 
implementation it turned out pretty simple).  

One page only links to a limited number of other pages (under 20 
would probably cover 90% of the pages in the wiki). So only those 
pages need to be updated (a fast task), and you're really only 
updating their pre-rendered info page.  

In addition, page edits are rare compared with page views (we see 
about 10 page edits a day if we're lucky) so the page editing 
process can be pretty expensive and slow.

As far as contention, i'd ignore it.  it should be rare (once again, we 
see only 10 page edits a day if we're lucky), and the info page is 
only a guide.  if its wrong by a link or two, give or take, its not the 
end of the world.  it will get fixed the next time another page 
adds/removes a link to it, or the page itself gets edited.  I suppose 
if it really bothers you, we can also just include a link on the page 
that the user can use to manually refresh the info it looks 
suspect... i'd say its not needed (added complexity for developer, 
maintainer, and user with limited additional utility).

> *: It would be interesting to write a WikiFormatter for emails :) **:

Definitely.  And for java and php source code....

> Which brings up the question of generating the global information page.  
> I think once-a-day (e.g. by cron) or from the admin pages on-demand is a
> good way to go about it; on-the-fly generation will be rather expensive,
> and there's probably not a good way to pre-render/cache it -- every edit
> would have update things, which would get messy.

Agreed.  Athough, at least with our JOS wiki, it will probably be 
less cpu expensive to do it every time a page is edited.  We have 
many days where no edits occur at all, and it rare to see more than 
5 or 6 edits a day.  I imagine, when a wiki is new, there are a lot of 
edits, but not much info to process, and as the wiki matures, there 
are less edits as the information becomes more comprehensive 
and starts to be used more for reference (reading only) rather than 
constant edits.

-iain

Re: [sfWiki-devel] integration with SF code?

[Iain S. C. M. <cr...@me...>]

On 20 May 00, at 16:21, Todd L. Miller wrote:

> 	While I think it would unnecessarily constrain potential users,
> what do you think about maintaining/submitting patches to the
> SourceForge code, integrating the Wiki more fully into SourceForge?  Any
> kind of work in this direction is (probably) a long ways off, but it's
> worth thinking about...

Since we are calling it sourceforge wiki, i don't see why we 
shouldn't integrate it tightly with sourceforge.  If its done right (with 
a well named, and well designed api), it should be easy for users 
that don't want to use sourceforge to rewrite or disable sourceforge 
specific features.

-iain