21 Jul
2004
21 Jul
'04
7:13 a.m.
We spent a day at Camp Smalltalk working with the old version of SmallWiki
and have been spending some time with the new one.
In the old one, Folder was a subclass of Page. This was reasonable. In the
new one, Page is a subclass of Folder, and this seems wrong. It looks like
Folder is never used, and all Pages can be Folders.
The worst part of the old SmallWiki was the callbacks. They are a horrible
design, virtually impossible to understand. I had hoped that the Seaside
version would fix them, but it didn't. Actions went away, and they weren't
that bad, aside from the callbacks. So, tell us why the Seaside version is
an improvement? In my opinion, it is a big step backward.
One of the bad features of the Seaside version is that actions are performed
in the user interface, not in the model. For example, a page is edited in
the #save version of EditRenderer, but in the accept (or maybe document:)
method of DocumentEditor. It looks like DocumentEditor does not create
history, so the trippy interface does something different from the Seaside
interface. This bug is due partly to bad design. There should be a single
place where documents are edited, like an Action. The model should change
the model.
We got an error in the new SmallWiki whenever we tried to put a new link on
a page. Is there a newer version?
-Ralph Johnson
21 Jul
21 Jul
2:07 p.m.
Hi,
thanks for the valuable feedback!
In the old one, Folder was a subclass of Page. This
was reasonable.
In the
new one, Page is a subclass of Folder, and this seems wrong. It looks
like
Folder is never used, and all Pages can be Folders.
I decided not to support pages anymore, as people didn't understand the
difference between Pages and Folder. Now the idea is, that all the
Pages can potentially have children.
The worst part of the old SmallWiki was the callbacks.
They are a
horrible
design, virtually impossible to understand. I had hoped that the
Seaside
version would fix them, but it didn't. Actions went away, and they
weren't
that bad, aside from the callbacks. So, tell us why the Seaside
version is
an improvement? In my opinion, it is a big step backward.
In my opinion callbacks are great. They make a huge improvement of the
abstraction over the dumb and error prone HTTP-protocol: basically they
remove all the manual handling of request and response fields.
Seaside provides a lot of functionality in a much better tested and
designed manner, that I implemented on my own in SmallWiki 1. The
possibility to have state in components make a big improvement over the
old SmallWiki implementation, e.g. see the interface to edit resources
(something like this would have been almost impossible with SmallWiki
1).
One of the bad features of the Seaside version is that
actions are
performed
in the user interface, not in the model. For example, a page is
edited in
the #save version of EditRenderer, but in the accept (or maybe
document:)
method of DocumentEditor.
I don't understand.
What I want is a separation of the model (SmallWiki-Model), the
controller (SmallWiki2-Seaside) and View (SmallWiki2-Seaside).
Eventually more code from the controller part should be moved to the
model.
It looks like DocumentEditor does not create history,
so the
trippy interface does something different from the Seaside
interface.
The trippy interface was just a test of the model. It isn't complete at
all and I didn't update it anymore since working on the seaside
interface.
This bug is due partly to bad design. There should be
a single
place where documents are edited, like an Action. The model should
change the model.
Yes, I see. I will try to move more of the controller code to the
model. But unfortunately my time is very very limited. So don't expect
changes soon.
We got an error in the new SmallWiki whenever we tried
to put a new
link on a page. Is there a newer version?
The link functionality is currently not implemented.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
11:05 p.m.
In my opinion callbacks are great. They make a huge
improvement of the
abstraction over the dumb and error prone HTTP-protocol: basically they
remove all the manual handling of request and response fields.
Callbacks make your system impossible to understand. Half a dozen
experienced Smalltalkers have been banging our heads against the callbacks
for three days.
We are trying to find out when to commit an action, and what arguments the
action used. Because the request is handled automatically, it is hard (it
may be impossible) to intercept the request. Because the callbacks in an
action are executed multiple times, it is hard to tell when something
important it happening.
You are falling into the fallacy that shorter code makes for a simpler
system. Callbacks might be easy for you to write, but they are hard for
everybody else to read, and in the long run are a bad idea.
I would MUCH prefer a completely manual handling of request and response
fields.
-Ralph Johnson
11:44 p.m.
Hi ralph
Are you talking about the old SmallWiki (one) or the new one with
Seaside?
Because I can understand that the old one may be difficult to
understand since lukas
tried to minic seaside wtihout seaside. But now when you read the code
of the store shop provided
as an example for seaside I do not understand how callbacks would make
code difficult to read.
When I see the complexity of the code and compare with the one of
seaside, I'm puzzled.
So can you clarify that point?
Thanks
On 21 juil. 04, at 23:05, Ralph Johnson wrote:
In my opinion
callbacks are great. They make a huge improvement of the
abstraction over the dumb and error prone HTTP-protocol: basically
they
remove all the manual handling of request and response fields.
Callbacks make your system impossible to understand. Half a dozen
experienced Smalltalkers have been banging our heads against the
callbacks
for three days.
We are trying to find out when to commit an action, and what arguments
the
action used. Because the request is handled automatically, it is hard
(it
may be impossible) to intercept the request. Because the callbacks in
an
action are executed multiple times, it is hard to tell when something
important it happening.
You are falling into the fallacy that shorter code makes for a simpler
system. Callbacks might be easy for you to write, but they are hard
for
everybody else to read, and in the long run are a bad idea.
I would MUCH prefer a completely manual handling of request and
response
fields.
-Ralph Johnson
22 Jul
22 Jul
3:17 p.m.
Just have to throw in my 2 cents, VisualWave which has been around for
years did shield developers from having to deal with request and response
fields, yet I don't recall it being that painful to debug/walk thru the
guts of Wave. There is a balance between convenience and
understandability. Mind you, I have not had a chance to yet walk-thru the
code myself but I trust that if six senior Smalltalkers which includes
Ralph are having a hard time that there is probably room for improvement :)
which brings up the fact that I tried to run the CallbackDemo i.e. as per
the instructions on the pdf and got the following:
Unhandled exception: BlockClosure [] in Object>>doesNotUnderstand:
SmallWiki.HtmlWriteStream(Object)>>doesNotUnderstand:
SmallWiki.HtmlWriteStream>>doesNotUnderstand:
optimized [] in SmallWiki.CallbackDemo>>renderFormRadioGroup
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
optimized [] in SmallWiki.HtmlWriteStream>>form:action:
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>form:
SmallWiki.HtmlWriteStream>>form:action:
SmallWiki.CallbackDemo(SmallWiki.Action)>>renderForm:
SmallWiki.CallbackDemo>>renderFormRadioGroup
SmallWiki.CallbackDemo>>renderForm
SmallWiki.CallbackDemo>>renderContent
optimized [] in SmallWiki.TemplateBodyContents>>renderBodyWith:on:
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
optimized [] in SmallWiki.TemplateBody>>renderDivFor:on:with:
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>div:
SmallWiki.HtmlWriteStream>>divNamed:with:
SmallWiki.TemplateBodyContents(SmallWiki.TemplateBody)>>renderDivFor:on:with:
SmallWiki.TemplateBodyContents>>renderBodyWith:on:
optimized [] in [] in SmallWiki.Action>>renderBody
OrderedCollection>>do:
optimized [] in SmallWiki.Action>>renderBody
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>div:
SmallWiki.HtmlWriteStream>>divNamed:with:
SmallWiki.CallbackDemo(SmallWiki.Action)>>renderBody
optimized [] in [] in SmallWiki.Action>>render
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>body:
optimized [] in SmallWiki.Action>>render
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>html:
SmallWiki.CallbackDemo(SmallWiki.Action)>>render
SmallWiki.CallbackDemo(SmallWiki.Action)>>execute
optimized [] in SmallWiki.Structure>>processAction:
BlockClosure>>on:do:
SmallWiki.Folder(SmallWiki.Structure)>>processAction:
SmallWiki.Folder(SmallWiki.Structure)>>processSelf:
SmallWiki.Folder(SmallWiki.Structure)>>process:
optimized [] in SmallWiki.Server>>process:
BlockClosure>>on:do:
SmallWiki.SwazooServer(SmallWiki.Server)>>process:
SmallWiki.SwazooSite>>helpResolve:
Swazoo.URIResolution>>visitResource:
[] in Swazoo.URIResolution>>visitChildrenOf:advancing:
OrderedCollection>>do:
Swazoo.URIResolution>>visitChildrenOf:advancing:
Swazoo.URIResolution>>resolveTransparentComposite:
Swazoo.URIResolution>>resolveServerRoot:
Swazoo.ServerRootComposite>>helpResolve:
Swazoo.URIResolution>>visitResource:
Swazoo.URIResolution class>>resolveRequest:startingAt:
Swazoo.HTTPServer>>answerTo:
optimized [] in Swazoo.HTTPConnection>>getAndDispatchMessages
BlockClosure>>on:do:
Swazoo.HTTPConnection>>getAndDispatchMessages
optimized [] in [] in Swazoo.HTTPConnection>>interact
BlockClosure>>on:do:
optimized [] in Swazoo.HTTPConnection>>interact
BlockClosure>>on:do:
optimized [] in Process class>>forBlock:priority:
----------------------------------------------------------------------
SmallWiki.HtmlWriteStream(Object)>>doesNotUnderstand:
Receiver:
a SmallWiki.HtmlWriteStream
Instance Variables:
collection = '<!DOCTYPE html PUBLIC "-//W3C...
In the meanwhile, since I am new to SmallWiki, it would be very helpful if
somebody documented the key spots in the code one should study
On Wed, 21 Jul 2004 23:44:04 +0200, stéphane ducasse
<ducasse(a)iam.unibe.ch> wrote:
Hi ralph
Are you talking about the old SmallWiki (one) or the new one with
Seaside?
Because I can understand that the old one may be difficult to understand
since lukas
tried to minic seaside wtihout seaside. But now when you read the code
of the store shop provided
as an example for seaside I do not understand how callbacks would make
code difficult to read.
When I see the complexity of the code and compare with the one of
seaside, I'm puzzled.
So can you clarify that point?
Thanks
On 21 juil. 04, at 23:05, Ralph Johnson wrote:
>> In my opinion callbacks are great. They make a huge improvement of the
>> abstraction over the dumb and error prone HTTP-protocol: basically they
>> remove all the manual handling of request and response fields.
>
> Callbacks make your system impossible to understand. Half a dozen
> experienced Smalltalkers have been banging our heads against the
> callbacks
> for three days.
>
> We are trying to find out when to commit an action, and what arguments
> the
> action used. Because the request is handled automatically, it is hard
> (it
> may be impossible) to intercept the request. Because the callbacks in
> an
> action are executed multiple times, it is hard to tell when something
> important it happening.
>
> You are falling into the fallacy that shorter code makes for a simpler
> system. Callbacks might be easy for you to write, but they are hard for
> everybody else to read, and in the long run are a bad idea.
>
> I would MUCH prefer a completely manual handling of request and response
> fields.
>
> -Ralph Johnson
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
24 Jul
24 Jul
12:49 a.m.
New subject: Camp Smalltalk results
We looked at the Seaside version of SmallWiki and decided it did not work
well enough. We were adding security features. Since security depends on
Actions, and since the Seaside version didn't have Actions, it seemed like
it would not be a good base for work. Links don't work. I imagine lots of
other things wouldn't work, but that was enough to persuade me to keep
working with the older version.
The main problem with the old version is that Actions are a mixture of
Commands (a model idea) and GUI. We tried for several days to treat Actions
like real Commands and to write them out to a log, but we eventually gave up
on that and instead used the Storage system to create a log. I know several
things wrong with our current implementation, but we can fix them with
enough work. Life would have been much easier if Actions had been only
commands and we could have written them to a log and then restored them to
recover the log. However, the use of callbacks made that impossible.
Callbacks are probably not as bad as I claimed a few days ago. We were
trying to do things with Actions that they were not designed to do. However,
it is often hard to tell what a framework can do. Normally it is possible
to write Commands to a log. It is not possible to write Actions to a log if
you intend to execute them after you read them back.
We added persistence to SmallWiki by having each page-change write to a log.
You can recover from a crash by restarting the latest image and reading the
log. We also added a VirtualFolder that allows one user to access a set of
pages with a particular name that are in other users folders. I plan to use
this in a course I teach. We wrote some actions that will help administer
these classes. There are a few more things that need to be done before
SmallWiki can replace our WikiWorks server, but we are getting close, and I
understand it much better now.
Actions are very important. I don't understand why the Seaside version
doesn't have it. Probably it is just because it is incomplete.
It is a mistake to make page and folder be the same. How can you make new
pages without using the component editor? New pages on a page should be in
the same folder, new pages on a folder should be inside that folder. What
would you do if there were no difference between pages and folders?
Seaside will make Actions simpler. However, it is possible to make Actions
simpler without Seaside. Callbacks should assign values ONLY to instance
variables of Actions. Once the Action is complete, it should be
"completed". This would make the behavior of each action easy to
understand. They could also be used in logs. It might even be easy to
refactor them to be like this. I might look at it next week.
-Ralph
3:41 p.m.
New subject: Camp Smalltalk results
Hi ralph
Thanks for your effort and feedback.
For the security issues we have an extension of Lukas original model
(or UI based on the original model of lukas). You can find the master
report of David Vogel on http://kilana.unibe.ch:9090/smallwiki/.
Now the problem that we have is that the code is breaking certain parts
of SmallWiki
and david is not replying to emails (since I guess that he is getting
married).
So we know that a UI and a better security model is needed (the idea of
the new version is
that a local admin should not be able to grant more rights than he
owns, and that a local admin cannot damage other local admins). But
right now we are stuck. We will see how/if this is worth to rescue the
code of David Vogel or just to reimplement the idea.
We are working on some administration actions:
- find all the deadlinks
- find all the pages with more than x links...
For that Frederic Bulckaen started to introduce the notion of tags and
their meta-description
and build a simple query engine based on that.
The version 2 of Seaside seems to be immature to start to work on it.
Normally monday we will have a discussion about it.
Stef
On 24 juil. 04, at 00:49, Ralph Johnson wrote:
We looked at the Seaside version of SmallWiki and
decided it did not
work
well enough. We were adding security features. Since security
depends on
Actions, and since the Seaside version didn't have Actions, it seemed
like
it would not be a good base for work. Links don't work. I imagine
lots of
other things wouldn't work, but that was enough to persuade me to keep
working with the older version.
The main problem with the old version is that Actions are a mixture of
Commands (a model idea) and GUI. We tried for several days to treat
Actions
like real Commands and to write them out to a log, but we eventually
gave up
on that and instead used the Storage system to create a log. I know
several
things wrong with our current implementation, but we can fix them with
enough work. Life would have been much easier if Actions had been only
commands and we could have written them to a log and then restored
them to
recover the log. However, the use of callbacks made that impossible.
Callbacks are probably not as bad as I claimed a few days ago. We were
trying to do things with Actions that they were not designed to do.
However,
it is often hard to tell what a framework can do. Normally it is
possible
to write Commands to a log. It is not possible to write Actions to a
log if
you intend to execute them after you read them back.
We added persistence to SmallWiki by having each page-change write to
a log.
You can recover from a crash by restarting the latest image and
reading the
log. We also added a VirtualFolder that allows one user to access a
set of
pages with a particular name that are in other users folders. I plan
to use
this in a course I teach. We wrote some actions that will help
administer
these classes. There are a few more things that need to be done before
SmallWiki can replace our WikiWorks server, but we are getting close,
and I
understand it much better now.
Actions are very important. I don't understand why the Seaside version
doesn't have it. Probably it is just because it is incomplete.
It is a mistake to make page and folder be the same. How can you make
new
pages without using the component editor? New pages on a page should
be in
the same folder, new pages on a folder should be inside that folder.
What
would you do if there were no difference between pages and folders?
Seaside will make Actions simpler. However, it is possible to make
Actions
simpler without Seaside. Callbacks should assign values ONLY to
instance
variables of Actions. Once the Action is complete, it should be
"completed". This would make the behavior of each action easy to
understand. They could also be used in logs. It might even be easy to
refactor them to be like this. I might look at it next week.
-Ralph
5:31 p.m.
New subject: Camp Smalltalk results
Hi Stéphane,
after using the Squeak version of Smallwiki in a student project
(interfacing a Flash client via SOAP for dynamic visualiztions of
project history and activity) I agree with Ralph on a lot of the
problems he had with the actions design, but it still was way better
than trying to work with the old swiki code :-)
One thing that really bugs me though is the fact that Smallwiki is
maintained in VW. As a company we can not afford to buy VW just to run
Smallwiki and instead of spending some of the time I don't have ;-) on
porting, I would love to be able to invest that time into development
efforts directly.
Is there any chance you guys could be persuaded to switch to Squeak?
Michael
5:49 p.m.
New subject: About running Wiki on VWNC
Hi michael
This is mainly me that prefers SmallWiki in VW because we are also
using it for other experiences and teaching. Roel also has lectures
using VW. And I'm not teaching using Squeak for multiple reasons but
one is that the UI framework is really bad and second I do not want the
impression that Smalltalk is childish. We have enough problems not to
look strange and ridiculous to use smalltalk not to add more. We also
use VW because also Squeak VM are NOT stable on Unix (we had to write a
script to check if they are working, imagine).
Then we are not making money with SmallWiki so we can use the
non-commercial version of VW.
I guess that this is the same for you. James will let us know.
When we started SW, MC was really in its enfancy. If Squeak would have
a better package mechanism
and people would be willing to help and they would be in Squeak then
why not.
Now the point is if people are really willing to help lukas and they
prefer Squeak for me I do not care. But right now SmallWiki is a good
wiki and we should pay attention to it.
Stef
Hi Stéphane,
after using the Squeak version of Smallwiki in a student project
(interfacing a Flash client via SOAP for dynamic visualiztions of
project history and activity) I agree with Ralph on a lot of the
problems he had with the actions design, but it still was way better
than trying to work with the old swiki code :-)
I think that lot of the problems will be resolved with SmallWiki 2.
But it is also important to provide feedback to lukas and others. So
can you be more precise on the problems and how you would solve them?
One thing that really bugs me though is the fact that
Smallwiki is
maintained in VW. As a company we can not afford to buy VW just to run
Smallwiki
I will ask james about that. James what is the status of cincom on
that? Should a company running a wiki pay for VW? I think that this
would be a mistake because this could show how stable is the VM. But
just let us know.
and instead of spending some of the time I don't
have ;-) on porting,
I would love to be able to invest that time into development efforts
directly.
Is there any chance you guys could be persuaded to switch to Squeak?
Stef
8:27 p.m.
New subject: About running Wiki on VWNC
I think that lot of the problems will be resolved with
SmallWiki 2.
But it is also important to provide feedback to lukas and others. So can
you be more precise on the problems and how you would solve them?
Well, the answer depends on usage - academic/non-commercial usage is
free. If a company wants to run VW on a server for internal use, then they
would need a license. However, a commercial VW license isn't that
expensive for such usage
One thing that really bugs me though is the fact
that Smallwiki is
maintained in VW. As a company we can not afford to buy VW just to run
Smallwiki
I will ask james about that. James what is the status of cincom on that?
Should a company running a wiki pay for VW? I think that this would be a
mistake because this could show how stable is the VM. But just let us know. and instead of
spending some of the time I don't have ;-) on porting, I
would love to be able to invest that time into development efforts directly.
Is there any chance you guys could be persuaded to switch to Squeak?
Stef
25 Jul
25 Jul
12:16 a.m.
New subject: About running Wiki on VWNC
I think that
lot of the problems will be resolved with SmallWiki 2.
But it is also important to provide feedback to lukas and others. So
can you be more precise on the problems and how you would solve them?
Well, the answer depends on usage - academic/non-commercial usage is
free. If a company wants to run VW on a server for internal use, then
they would need a license. However, a commercial VW license isn't
that expensive for such usage One thing that really bugs me though is the fact
that Smallwiki is
maintained in VW. As a company we can not afford to buy VW just to
run Smallwiki
I will ask james about that. James what is the status of cincom on
that? Should a company running a wiki pay for VW? I think that this
would be a mistake because this could show how stable is the VM. But
just let us know. >> and instead of spending some of the time I
don't have ;-) on
>> porting, I would love to be able to invest that time into
>> development efforts directly.
>> Is there any chance you guys could be persuaded to switch to Squeak?
>
> Stef
1:48 a.m.
New subject: About running Wiki on VWNC
Well, the
answer depends on usage - academic/non-commercial usage is
free. If a company wants to run VW on a server for internal use, then
they would need a license. However, a commercial VW license isn't that
expensive for such usage
How much?
Which means that we may stop to develop smallwiki on VW then. I think that
this is the next logical consequence.
I do not understand then what is the situation for bottom feeder, it is
because you pay a license that you can offer it for free? Because
Smallwiki is exactly in the same situation as bottomFeeder.
Should I pay a license to use bottomFeeder if I'm working in a company and
using your tool during my working time?
Does it mean that if I want that my users can use a tool that I'm
developing for free that I have to pay a license? I think that you are
simply killing the use of VW for us then. There is also a really vicious side-effect for all the
tools that we are
developing in open-source. A programmer in a company using Moose (which is
open-source) would have to pay. So it seems that developing open-source
and VW are incompatible. To bad we will have to learn from that sad news.
I think that you are doing a mistake but I cannot change it so we will
have to adapt ourselves.
>>>and instead of spending some of the time I don't have ;-) on porting, I
>>>would love to be able to invest that time into development efforts directly.
>>>Is there any chance you guys could be persuaded to switch to Squeak?
>>
>>Stef
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
jarober(a)gosmalltalk.com
1:57 a.m.
New subject: About running Wiki on VWNC
James Robertson wrote:
>> Well, the answer depends on usage - academic/non-commercial usage is
>> free. If a company wants to run VW on a server for internal use,
>> then they would need a license. However, a commercial VW license
>> isn't that expensive for such usage
...
It really depends. I explicitly open sourced BottomFeeder, and I'm not
making money off it. So, if you put SmallWiki under an Open Source
license, you would also be ok on usage. It would be unsupported by
Cincom, but I suspect that's not really an issue here.
Hmm, isn't that a contradiction:
"If a company wants to run VW on a server for internal use, then they
would need a license. "
and
"So, if you put SmallWiki under an Open Source license, you would also
be ok on usage."
Let's try simple yes/no questions ;-)
- If I run Smallwiki on our company server for internal use, do I need
to pay or not?
- If I run Smallwiki on our company server for internal and external use
as the wiki for an OpenSource project, do I need to pay or not?
- If I run Smallwiki on our company server for internal and external use
as the wiki for a commercial project, do I need to pay or not?
I hate these kind of questions too and I appreciate your effort in
trying to answer them!
Thanks
Michael
10:38 a.m.
New subject: About running Wiki on VWNC
Hi james
Hmm, isn't that a contradiction:
"If a company wants to run VW on a server for internal use, then they
would need a license. "
and
"So, if you put SmallWiki under an Open Source license, you would also
be ok on usage."
Let's try simple yes/no questions ;-)
- If I run Smallwiki on our company server for internal use, do I need
to pay or not?
- If I run Smallwiki on our company server for internal and external
use as the wiki for an OpenSource project, do I need to pay or not?
- If I run Smallwiki on our company server for internal and external
use as the wiki for a commercial project, do I need to pay or not?
I hate these kind of questions too and I appreciate your effort in
trying to answer them!
I want to know too because we are developing software which is
open-source and can be used by companies and I think that the position
of cincom should be clear for all of us.
You wrote: "It really depends. I explicitly open sourced BottomFeeder,
and I'm not making money off it. So, if you put SmallWiki under an
Open Source license, you would also be ok on usage. It would be
unsupported by Cincom, but I suspect that's not really an issue here."
SmallWiki is open source but I do not understand what is unsupported
here?
Thanks
24 Jul
24 Jul
8:22 p.m.
New subject: Camp Smalltalk results
For the security issues we have an extension of Lukas
original model
(or UI based on the original model of lukas). You can find the master
report of David Vogel on http://kilana.unibe.ch:9090/smallwiki/.
Now the problem that we have is that the code is breaking certain parts
of SmallWiki
and david is not replying to emails (since I guess that he is getting
married).
So we know that a UI and a better security model is needed (the idea of
the new version is
that a local admin should not be able to grant more rights than he
owns, and that a local admin cannot damage other local admins). But
right now we are stuck. We will see how/if this is worth to rescue the
code of David Vogel or just to reimplement the idea.
We used the "advanced security" system, which I think was David Vogel's.
We
did not find any bugs we couldn't fix. If you send a list of things that do
not work (especially test cases that fail) then I would be willing to look
at them.
One thing we found annoying was that the default wiki with advanced security
gives no permissions at all to the anonymous user. I think we changed
initialization so that anonymous users can read and write pages and create
new pages.
In general, all of the UIUC wiki will be open for reading and writing by any
user. However, I have a class where I would like to provide private folders
for each student. We made an action that will take a "students" folder with
a large number of subfolders and will automatically make users and roles for
each subfolder and set permisisons so that students can read and write their
own folders, but nobody else can read or write them. In this class,
students write short essays several times a week and take turns grading
them. I wanted to do this all on the wiki. The grader must be able to read
the essays, but nobody else can read them until they are all turned in. I
make a "VirtualFolder" structure that I can put in the folder of the grader.
If the student is supposed to grade essay 3, I will initialize the virtual
folder with the string "essay 3" and then the folder will act like it
contains every page named "essay 3" in any of the student folders. When the
grader is finished grading the essays, he can make his virtual folder
readable by the world, and then everybody can read the essays. The pages
representing the essays will have two URLs, their original one and the one
through the virtual folder. They will have different permssions depending
on which URL you use.
We got all this to work and I was pleased.
The advanced security system is complex, and security depends on roles being
assigned correctly. It would be useful to have some sort of an analysis
package that would make it easy to see who is allowed to do what to the
various parts of the wiki. For example, it could draw a diagram of the wiki
and color different parts with the roles that work on them. Until then, my
solution will be to keep things very simple. Except for this one class,
I'll just have the administrator and the anonymous role.
25 Jul
25 Jul
3:40 p.m.
New subject: Camp Smalltalk results
For the
security issues we have an extension of Lukas original model
(or UI based on the original model of lukas). You can find the master
report of David Vogel on http://kilana.unibe.ch:9090/smallwiki/.
Now the problem that we have is that the code is breaking certain
parts
of SmallWiki
and david is not replying to emails (since I guess that he is getting
married).
So we know that a UI and a better security model is needed (the idea
of
the new version is
that a local admin should not be able to grant more rights than he
owns, and that a local admin cannot damage other local admins). But
right now we are stuck. We will see how/if this is worth to rescue the
code of David Vogel or just to reimplement the idea.
We used the "advanced security" system, which I think was David
Vogel's. We
did not find any bugs we couldn't fix. If you send a list of things
that do
not work (especially test cases that fail) then I would be willing to
look
at them. One thing we found annoying was that the default wiki
with advanced
security
gives no permissions at all to the anonymous user. I think we changed
initialization so that anonymous users can read and write pages and
create
new pages.
Yes indeed this was strange.
In general, all of the UIUC wiki will be open for
reading and writing
by any
user. However, I have a class where I would like to provide private
folders
for each student. We made an action that will take a "students"
folder with
a large number of subfolders and will automatically make users and
roles for
each subfolder and set permisisons so that students can read and write
their
own folders, but nobody else can read or write them. In this class,
students write short essays several times a week and take turns grading
them. I wanted to do this all on the wiki. The grader must be able
to read
the essays, but nobody else can read them until they are all turned
in. I
make a "VirtualFolder" structure that I can put in the folder of the
grader.
If the student is supposed to grade essay 3, I will initialize the
virtual
folder with the string "essay 3" and then the folder will act like it
contains every page named "essay 3" in any of the student folders.
When the
grader is finished grading the essays, he can make his virtual folder
readable by the world, and then everybody can read the essays. The
pages
representing the essays will have two URLs, their original one and the
one
through the virtual folder. They will have different permssions
depending
on which URL you use.
We got all this to work and I was pleased.
This is nice. I would not have known how to make this works.
I think that SmallWiki will start to pay off as soon as you have non
basic needs and in the
long run we are winning.
The advanced security system is complex, and security
depends on roles
being
assigned correctly. It would be useful to have some sort of an
analysis
package that would make it easy to see who is allowed to do what to the
various parts of the wiki. For example, it could draw a diagram of
the wiki
and color different parts with the roles that work on them. Until
then, my
solution will be to keep things very simple. Except for this one
class,
I'll just have the administrator and the anonymous role.
Yes I agree having a overall picture is currently missing. I think that
with the new version
of SmallWiki building more advanced tools will be easier because writing
web widgets is not easy right now.
22 Jul
22 Jul
12:44 a.m.
On Jul 21, 2004, at 2:05 PM, Ralph Johnson wrote:
We are trying to find out when to commit an action,
and what arguments
the
action used. Because the request is handled automatically, it is hard
(it
may be impossible) to intercept the request. Because the callbacks in
an
action are executed multiple times, it is hard to tell when something
important it happening.
You are falling into the fallacy that shorter code makes for a simpler
system. Callbacks might be easy for you to write, but they are hard
for
everybody else to read, and in the long run are a bad idea.
I would MUCH prefer a completely manual handling of request and
response
fields.
Ralph,
I don't know the SmallWiki codebase, so I can't comment on the
specifics. But I can certainly speak to trade-offs between manual and
automatic request handling.
With all due respect, I think you should consider the possibility that
the problem is in your design, not Lukas'. IIUC, you're trying to
capture modifications to the model, but you're doing this at the
controller layer, or even lower: the equivalent to the Sensor in a
classic MVC system. Might it not work better if you intercepted the
actual messages sent to the model instead?
Now, I admit that a simpler (more verbose, harder to maintain) UI
architecture would make it easier for you to do the wrong thing here,
and intercept at the UI level instead of the model level. By analogy,
it would be very easy to create a "prevayler" system for a unix
filesystem by capturing all the shell commands and playing them back.
It would be much harder, and much less reliable, to capture all the
mouse clicks and keystrokes handled by the Mac OS X Finder to do the
same tasks, because it processes them "automatically" - which is to
say, those events have no semantics out of the context in which they
were made. You would probably be very frustrated if you decided you
were going to implement a journalled filesystem by capturing and
replaying all the UI events sent to the Finder application, but I'm not
wholly convinced that it would be the fault of poor design on the part
of the Finder. Nor am I convinced that we should all be writing
command line tools exclusively, or that we should manually process
every mouse click in a GUI application we're writing, on the grounds
that it's "easier to read" (though certainly harder to write) that way.
I'm not trying to dismiss your concerns - clearly there is a problem
here, and I'd like to explore it further. But I thought an alternate
point of view might be interesting.
Avi
7208
days inactive
7212
days old
16 comments
7 participants
participants (7)
-
Avi Bryant -
Charles A. Monteiro -
James Robertson -
Lukas Renggli -
Michael Rueger -
Ralph Johnson -
stéphane ducasse