>(Bounced non-member submission) >Date: Fri, 17 Mar 2000 13:48:52 +0100 >From: "Baveco, Dr. J.M." <[EMAIL PROTECTED]> >Subject: RE: [pws] The Near Future of Swiki >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> >Message-id: <[EMAIL PROTECTED]> >MIME-version: 1.0 >X-Mailer: Internet Mail Service (5.5.2650.21) >Content-type: text/plain; charset="iso-8859-1" > >Hi Jochen, > >with respect to new features: > >I am currently using swikis on our intranet. They serve well as shared >project-spaces, mainly used to store all kinds of documentation. Each >project I have, has a swiki assigned to it. The acceptance of this way of >working, especially when scaling up to the whole institute (600 employees), >would be greatly enhanced when there was a more structured way of storing >documents (their retrieval is structured, I know, but that's not enough). >Now, they all end up in the uploads directory, and the perspective of >thousands of documents being there is scaring (in case the swiki doesn't >work properly anymore, how am I going to find my way through all these >documents). One solution could be storing the documents in a database where >the swiki has direct access to. A temporary solution may be to look for a >way to structure the uploads area (I noticed one can retrieve documents from >subdirectories of the uploads directory, with e.g. *+/subdir/filename+*, but >of course the contents of these subdirectories do no show up anywhere on the >swiki. >Another but related aspect: it would be nice when such swikis could be >easily archived. E.g. after a project is finished and nothing should be >changed and added anymore, the whole swiki is moved to CD (can be done >already now). The new feature should be that archived swikis can be accessed >in the same way as running swikis, (but read-only, from the CD, skipping all >the network stuff - maybe the CD should contain the squeak vm and image to >open the archived swiki with as well). This would diminish the need for real >database access, may be. >I am afraid I can not more clearly point out what I think should be >available, but I really think that some kind of "safe, structured, >archiveable document storage" is required to make swikis a success on (our) >intranet. > > >thanks for all your efforts, > >hans > > > > -----Original Message----- > > From: Jochen F. Rick [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, March 16, 2000 11:22 PM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: [pws] The Near Future of Swiki > > > > I think it is time I wrote as to what my vision for Swiki is and how I > > see others fitting into it. > > > > You may have noticed that I still consider Swiki betaware. To me, this > > means that I am not guaranteeing anything and I am free to change any > > code I like. I feel that Swiki needs a strong, flexible and elegant core, > > before I officially release it. Right now, I don't feel this to be the > > case. The code in SwikiRequest, security, initialization, and talking to > > Comanche needs to get cleaned up. At the same time, the admin swiki also > > still needs major work and the uploads area could use some work too. > > Until I am satisfied with these areas and a few others, I will not > > officially release Swiki. Right now, I'm estimating that there will not > > be a Beta 13. Probably, the difference between Beta 12 and Release 1 will > > be bug fixes and better documentation. > > > > What does this mean for the larger community of swiki developers? We have > > been having the problem that people are diverging from the code and then > > not being able to upgrade to the newest code. For instance, Swiki.net > > diverged so early that the code is probably very incompatible. Probably, > > Bert and Bijan are facing the same problems. So, this seems to me like > > the best strategy for this development to be productive for everyone: > > > > Phase I (Before Release 1) > > 1) Let me know what you'd like to see in the core software. By this I mean > > things like Bert requesting that it be possible to do partial returns. > > 2) Let me know what problems you are having with implementing new > > features. > > For instance, lack of documentation (besides asking Bijan), not being > > able to fully support a different language in just files, etc. > > 3) Forgive me that some of your code may not work in an upgrade. Although, > > messing around in templates, actions, settings, etc. will probably be > > okay. > > > > Phase II (After Release 1) > > 1) We need new packages. So far, I have refs, docs, and forward packages. > > Once the core is stabilized, creating new packages (or goodies) will > > become essential. I know that Bijan is working on a new formatter. I > > would like for goodies like these to be just as available as the > > standard packages. > > 2) We need more tools. I realize that working with FileList is not > > particularly pleasant. One tool we could definitely use is something > > that allows for easier editing of templates, actions, etc. I feel it > > is a bit premature to work on this before the core has settled. But, > > after release 1, these types of tools would be great. > > 3) We could use other storage mechanisms. Right now, XML is hard coded in, > > but other things such as databases might make some sense. > > > > So, I hope that gives sort of a vision of where Swiki is going in the not > > too distant future. > > > > Thanks for all your help, > > > > Je77 -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : [EMAIL PROTECTED] http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
