ST/X Users Swiki & Wiki Farms 
Author Message
 ST/X Users Swiki & Wiki Farms

Any ST/X users out there? - http://www.*-*-*.com/

It is a shame that swiki.net is not very reliable, I am thinking of
starting my own wiki farm.
------
I want to develop an industrial strength wiki farm with web based
management.

I have a short term plan and a long term plan. Long term I would like to
do everything in Smalltalk, either squeak and/or ST/X (compiled for
speed). But in the short term my current solution for developing a wiki
farm would be to take the design of 'swiki' and possibly some features
of 'usemod' and implement it in Zope, to take advantage of persistence,
scalability, web based admin, user roles/permissions, and hierarchical
acquisition/scripts and templates. However Zope/python at first glance
seems like a bit of a pig to develop with.

Has anyone got any thoughts on the way to go for a wiki farm with
hierarchical template acquisition (zope jargon) and end user control.
Maybe I have missed something but pws does not appear to be aiming to
put its templates in the hands of the end users, or 'sub wiki' owners.

any ideas ?  thanks in advance

Keith



Mon, 17 May 2004 19:57:38 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:

> Any ST/X users out there? - http://stx.swiki.net

> It is a shame that swiki.net is not very reliable, I am thinking of
> starting my own wiki farm.
> ------
> I want to develop an industrial strength wiki farm with web based
> management.

> I have a short term plan and a long term plan. Long term I would like to
> do everything in Smalltalk, either squeak and/or ST/X (compiled for
> speed). But in the short term my current solution for developing a wiki

I think you ought to look at VisualWorks and the Wiki code for it - VW
is pretty much the fastest Smalltalk out there.
Quote:
> farm would be to take the design of 'swiki' and possibly some features
> of 'usemod' and implement it in Zope, to take advantage of persistence,
> scalability, web based admin, user roles/permissions, and hierarchical
> acquisition/scripts and templates. However Zope/python at first glance
> seems like a bit of a pig to develop with.

> Has anyone got any thoughts on the way to go for a wiki farm with
> hierarchical template acquisition (zope jargon) and end user control.
> Maybe I have missed something but pws does not appear to be aiming to
> put its templates in the hands of the end users, or 'sub wiki' owners.

> any ideas ?  thanks in advance

> Keith



Mon, 17 May 2004 21:25:05 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:

>Has anyone got any thoughts on the way to go for a wiki farm with
>hierarchical template acquisition (zope jargon) and end user control.
>Maybe I have missed something but pws does not appear to be aiming to
>put its templates in the hands of the end users, or 'sub wiki' owners.

WikiWorks is a wiki in VisualWorks.  There is a farm at
http://wiki.cs.uiuc.edu.  We used to run it on a Pentium 90
with 32 meg of memory running Linux.  Eventually the image
got to be about 20 meg and the system started to thrash so
it now runs on a Pentium 260 with 300 meg or so running Linux.
We recently discovered a stupid performance problem that we
haven't yet fixed.  It is fast enough now; if we fix that
bottleneck it should be able to handle 10 times the traffic.

We don't have end user control, though I think it would be easy to
have it.  I think we *do* have hierarchical template aquisition.
WikiWorks has a simple "active Smaltalk pages" template system,
and every wiki can have its own style.  It is also easy to make
Smalltalk servlets, though it is dangerous to allow users to
download their code to the system.  

If you want to customize WikiWorks, you might want to talk to Joel

We are always looking for improvements.

-Ralph Johnson



Mon, 17 May 2004 22:41:54 GMT  
 ST/X Users Swiki & Wiki Farms
The latest ComSwiki is much more customizable by end users than PWS.  If you
start with Squeak, make sure to start with ComSwiki.

With respect to Swiki.net stability, I'm hoping to get a chance to address
that issue over the next few months.  There are a number of reasons why
Swiki.net goes down (Windows NT issues, Squeak 2.5, our custom socket
interface, etc).  Most recently (Monday), I remotely rebooted the server (a
Windows NT machine) and it didn't properly restart.  I didn't have a chance
to get to our hosting location until yesterday to physically reboot it.  I'd
like to move to a Unix server, upgrade to Squeak 3.1, and address a couple
of performance issues in the code.

- Stephen


Quote:
> Any ST/X users out there? - http://stx.swiki.net

> It is a shame that swiki.net is not very reliable, I am thinking of
> starting my own wiki farm.
> ------
> I want to develop an industrial strength wiki farm with web based
> management.

> I have a short term plan and a long term plan. Long term I would like to
> do everything in Smalltalk, either squeak and/or ST/X (compiled for
> speed). But in the short term my current solution for developing a wiki
> farm would be to take the design of 'swiki' and possibly some features
> of 'usemod' and implement it in Zope, to take advantage of persistence,
> scalability, web based admin, user roles/permissions, and hierarchical
> acquisition/scripts and templates. However Zope/python at first glance
> seems like a bit of a pig to develop with.

> Has anyone got any thoughts on the way to go for a wiki farm with
> hierarchical template acquisition (zope jargon) and end user control.
> Maybe I have missed something but pws does not appear to be aiming to
> put its templates in the hands of the end users, or 'sub wiki' owners.

> any ideas ?  thanks in advance

> Keith



Tue, 18 May 2004 00:04:39 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:
>I want to develop an industrial strength wiki farm with web based
>management.

Coolness. I host a bunch of Squeak Swiki's (like the SqueakFoundation stuff)
and I'm always interested in better, bigger, meaner solutions. If you have
something and want hosting, drop me a note.

Quote:
>However Zope/python at first glance
>seems like a bit of a pig to develop with.

I really hate it that one of the Zope guys actually sat in the ANSI Smalltalk
committee and they still decided to go with Python. I've tried to develop apps
with Zope, but it is not there yet.

Quote:
>Has anyone got any thoughts on the way to go for a wiki farm with
>hierarchical template acquisition (zope jargon) and end user control.
>Maybe I have missed something but pws does not appear to be aiming to
>put its templates in the hands of the end users, or 'sub wiki' owners.

My preferred environment at the moment is VW Webtoolkit plus OmniBase.
Technically, I prefer Squeak's SSP (because they don't have all the Java JSP
compatibility braindamage on board and because you can 'in-line' them in
Smalltalk methods), but VW has better source code management, performance, and
stability. OmniBase does most everything that ZODB does, and then some, so I
think that VW+WikiWorks+OmniBase+WebToolkit somehow integrated would be a
great platform for a Wiki farm.

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Mon, 17 May 2004 23:11:08 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:

> My preferred environment at the moment is VW Webtoolkit plus OmniBase.
> Technically, I prefer Squeak's SSP (because they don't have all the Java JSP
> compatibility braindamage on board and because you can 'in-line' them in
> Smalltalk methods), but VW has better source code management, performance, and
> stability. OmniBase does most everything that ZODB does, and then some, so I
> think that VW+WikiWorks+OmniBase+WebToolkit somehow integrated would be a
> great platform for a Wiki farm.

Cees,

        could you say more about what you like about the SSP facilities and
what you'd like to see in VW?  We'll try and oblige :)

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd



Tue, 18 May 2004 02:44:19 GMT  
 ST/X Users Swiki & Wiki Farms
Eliot,

I can't speak for why Cees likes SSP, but I can offer insight into the
implementation:

Squeak's SSP is only an enhancement to the parser the allows you to use an
SSP like syntax in the browser via an <ssp> pragma.  It's use is more
general than building HTML/XML pages (you could use it anywhere you want to
build a stream of characters and embed object state in the stream).  You can
download SSP and find more details at: http://ssp-squeak.swiki.net  (it's
also is included in ComSwiki I believe).  Swiki.net uses this mechanism to
assemble its pages.

I like this approach because my HTML code hangs as methods on real objects
as opposed to disconnected .ssp files (it feels more OO to me).  Also, I
found that I could create "presenters" that spit out a chunk of HTML for
their respective domain object and assemble an entire HTML page in a very
modular and re-usable way (a look policy governs what specific presenter is
used for any given domain object).  Most of the SSP methods in Swiki.net are
no more than 10-15 lines long.  When building a page, we would start by
mocking it up in an HTML editor, then when we got it the way we liked it, we
would pull apart the HTML source an install it on the respective presenters
as SSP methods.

Of course, the more traditional JSP style is going to be more familiar to
most people I think.

With SSP you might write the following:

Person>>formattedNameAndAddressOn: strm
<ssp on: strm>

A Person:
 Name: <%= name %>
 Address: <%= address %>

...which would compile to the equivalent of:

Person>>formattedNameAndAddressOn: strm
 strm nextPutAll: 'A Person:
 Name: '.
 name sspStreamOn: strm.
 strm nextPutAll: '
 Address: '.
 address sspStreamOn: strm

- Stephen


Quote:


> > My preferred environment at the moment is VW Webtoolkit plus OmniBase.
> > Technically, I prefer Squeak's SSP (because they don't have all the Java
JSP
> > compatibility braindamage on board and because you can 'in-line' them in
> > Smalltalk methods), but VW has better source code management,
performance, and
> > stability. OmniBase does most everything that ZODB does, and then some,
so I
> > think that VW+WikiWorks+OmniBase+WebToolkit somehow integrated would be
a
> > great platform for a Wiki farm.

> Cees,

> could you say more about what you like about the SSP facilities and
> what you'd like to see in VW?  We'll try and oblige :)

> --
> _______________,,,^..^,,,____________________________
> Eliot Miranda              Smalltalk - Scene not herd



Tue, 18 May 2004 03:45:19 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:
>    could you say more about what you like about the SSP facilities and
>what you'd like to see in VW?  We'll try and oblige :)

I've mentioned this to Alan once last Summer - the biggest problem with
SSP's now is that they are external files so you cannot maintain them
with StORE. Furthermore, Stephen Pair's Squeak SSP implementation is
very lightweight, it expects a lot less environment, and therefore it
is usable e.g. to generate mails etcetera without a Web serving context.

Squeak SSP's are in methods, with a special primitive signaling the
compiler that the rest of the method is to be treated as an SSP. I think
the introduction is '<ssp: streamArg>' where streamArg refers to the temp
or parameter where the compiler should stream the result to. Stephen is
on this list, so he'll correct my shady memories :-).

(BTW, I think that Zope's new Page Templates are even cooler than SSP's. The
basic idea is:

<tag zopeSpecialAttributeName="some zope code">dummy contents</tag>

By putting all the code in the attributes you can use any web design tool that
respects attributes when reading/writing HTML (as far as I know, almost all of
them do) and the designer can insert dummy contents to get a feel for the
completed page. When Zope renders the template, it ignores the dummy contents
and writes the actual result of executing "some zope code". I think it's an
idea worth stealing, because it stands a good chance of letting programmers
and web designers cooperate more peacefully :-)).

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Tue, 18 May 2004 04:33:13 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:
> (BTW, I think that Zope's new Page Templates are even cooler than SSP's.

Take a look at XMLC. Even cooler still. http://xmlc.enhydra.org/index.html (a Smalltalk version would be nice,
though)


Tue, 18 May 2004 05:49:40 GMT  
 ST/X Users Swiki & Wiki Farms


Quote:

>>     could you say more about what you like about the SSP facilities
>>     and
>>what you'd like to see in VW?  We'll try and oblige :)

> I've mentioned this to Alan once last Summer - the biggest problem with
> SSP's now is that they are external files so you cannot maintain them
> with StORE. Furthermore, Stephen Pair's Squeak SSP implementation is
> very lightweight, it expects a lot less environment, and therefore it
> is usable e.g. to generate mails etcetera without a Web serving
> context.

I think the external files vs. code in methods is very much a matter of
perspective. Smalltalk programmers who write html like html in methods, web
designers like html in files. In this first release we are very much
targeting standard mechanisms and the broader web community, so the things
they do got more emphasis. However, I'm certainly aware of the mechanisms
that let you use a special parser to store pages as methods, and we're
pretty close to that with the x-ssp URLs. It just needs a couple more
steps, which are on my to-do list, they just hasn't gotten to the top yet.

Being able to use the ssp mechanism without the web-serving infrastructure
is interesting. I'll have to think about that one.

Quote:
> Squeak SSP's are in methods, with a special primitive signaling the
> compiler that the rest of the method is to be treated as an SSP. I
> think the introduction is '<ssp: streamArg>' where streamArg refers to
> the temp or parameter where the compiler should stream the result to.
> Stephen is on this list, so he'll correct my shady memories :-).

> (BTW, I think that Zope's new Page Templates are even cooler than
> SSP's. The basic idea is:

><tag zopeSpecialAttributeName="some zope code">dummy contents</tag>

> By putting all the code in the attributes you can use any web design
> tool that respects attributes when reading/writing HTML (as far as I
> know, almost all of them do) and the designer can insert dummy contents
> to get a feel for the completed page. When Zope renders the template,
> it ignores the dummy contents and writes the actual result of executing
> "some zope code". I think it's an idea worth stealing, because it
> stands a good chance of letting programmers and web designers cooperate
> more peacefully :-)).

So is tag a regular HTML tag, e.g.
<a href="foo.html" zopeSpecialAttributeName="12 factorial">hello world</a>

or would you normally write this with a special or dummy tag.

If the latter, I'm pretty sure you could do this now as a custom tag.
Regardless I'm pretty sure I could hack the mechanism to do it quite
easily. Added to the to-do list.



Tue, 18 May 2004 07:31:04 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:
>Being able to use the ssp mechanism without the web-serving infrastructure
>is interesting. I'll have to think about that one.

Please do. It'd make it easy to send people confirmation mails, etcetera.

Quote:
>So is tag a regular HTML tag, e.g.
><a href="foo.html" zopeSpecialAttributeName="12 factorial">hello world</a>

>or would you normally write this with a special or dummy tag.

Regular HTML. There's also some support for looping, of course.

(http://www.zope.org/Wikis/DevSite/Projects/ZPT/FrontPage, specifically the
tutorials. Here's a loop:

     <table border="1" width="100%">
        <tr>
          <th>#</th><th>Id</th><th>Meta-Type</th><th>Title</th>
        </tr>
        <tr tal:repeat="item container/objectValues">
          <td tal:content="repeat/item/number">#</td>
          <td tal:content="item/id">Id</td>
          <td tal:content="item/meta_type">Meta-Type</td>
          <td tal:content="item/title">Title</td>
        </tr>
      </table>

with 'tal:xxx' being the special Zope attribute stuff and the contents of the
attributes being references to the ZPT's Zope context.

To the XMLC comment elsewhere in the thread: I remember I read the docs
and found it quite cool back when Lutris first released Enhydra. I would
need to get back to it - somehow the idea of using a compiled language
for web development has always been revolting to me, so I never seriously
looked at C/C++/Java web stuff. But back then XMLC seemd like one of these
rare actually useful applications of XML ;-)

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Tue, 18 May 2004 09:17:24 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:
>I think the external files vs. code in methods is very much a matter of
>perspective.

More so if/when StORE will be able to deal with external files. Really,
it removes so much power from StORE when you have to put all the .ssp
(and message catalog .lbl files, configuration .ini files, ...) in CVS...

Is something like that planned?

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Tue, 18 May 2004 09:26:51 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:
> If you want to customize WikiWorks, you might want to talk to Joel

> We are always looking for improvements.




Tue, 18 May 2004 14:13:50 GMT  
 ST/X Users Swiki & Wiki Farms
Would it not be nice to have an integrated environment that not only
allowed us to manage source code but also other resources such as
ssp's , ini files  etc? After all, a build is not just about the code
especially in web land.
Quote:




> >>     could you say more about what you like about the SSP facilities
> >>     and
> >>what you'd like to see in VW?  We'll try and oblige :)

> > I've mentioned this to Alan once last Summer - the biggest problem with
> > SSP's now is that they are external files so you cannot maintain them
> > with StORE. Furthermore, Stephen Pair's Squeak SSP implementation is
> > very lightweight, it expects a lot less environment, and therefore it
> > is usable e.g. to generate mails etcetera without a Web serving
> > context.

> I think the external files vs. code in methods is very much a matter of
> perspective. Smalltalk programmers who write html like html in methods, web
> designers like html in files. In this first release we are very much
> targeting standard mechanisms and the broader web community, so the things
> they do got more emphasis. However, I'm certainly aware of the mechanisms
> that let you use a special parser to store pages as methods, and we're
> pretty close to that with the x-ssp URLs. It just needs a couple more
> steps, which are on my to-do list, they just hasn't gotten to the top yet.

> Being able to use the ssp mechanism without the web-serving infrastructure
> is interesting. I'll have to think about that one.

> > Squeak SSP's are in methods, with a special primitive signaling the
> > compiler that the rest of the method is to be treated as an SSP. I
> > think the introduction is '<ssp: streamArg>' where streamArg refers to
> > the temp or parameter where the compiler should stream the result to.
> > Stephen is on this list, so he'll correct my shady memories :-).

> > (BTW, I think that Zope's new Page Templates are even cooler than
> > SSP's. The basic idea is:

> ><tag zopeSpecialAttributeName="some zope code">dummy contents</tag>

> > By putting all the code in the attributes you can use any web design
> > tool that respects attributes when reading/writing HTML (as far as I
> > know, almost all of them do) and the designer can insert dummy contents
> > to get a feel for the completed page. When Zope renders the template,
> > it ignores the dummy contents and writes the actual result of executing
> > "some zope code". I think it's an idea worth stealing, because it
> > stands a good chance of letting programmers and web designers cooperate
> > more peacefully :-)).

> So is tag a regular HTML tag, e.g.
> <a href="foo.html" zopeSpecialAttributeName="12 factorial">hello world</a>

> or would you normally write this with a special or dummy tag.

> If the latter, I'm pretty sure you could do this now as a custom tag.
> Regardless I'm pretty sure I could hack the mechanism to do it quite
> easily. Added to the to-do list.



Tue, 18 May 2004 14:22:08 GMT  
 ST/X Users Swiki & Wiki Farms

Quote:
> (BTW, I think that Zope's new Page Templates are even cooler than SSP's. The
> basic idea is:

> <tag zopeSpecialAttributeName="some zope code">dummy contents</tag>

I thought that too ZPT looked like an interesting thing, but in wiki land I
wonder how you
might present this power to your end user and so I was thinking of using the

*some optional text alias>some special wiki tag name* and having this map into a
Zope(style) Page Template for persistent store and later rendering.

Keith



Tue, 18 May 2004 18:40:00 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Wiki abused as link farm?

2. [ANNC] Smalltalk/X Users SWIKI (New)

3. Announcement: Puget Sound ST & OODBMS User Group

4. Cows, Hogs & Farms

5. Forth & Farming

6. Announcement: Puget Sound ST & OODBMS User Group

7. ST V / MAC & ST V / WIN

8. New Wiki page:"Tcl User Groups"

9. How to set up a Wiki Wiki Web

10. User Break in IBM ST

11. Ann: Puget Sound (WA,USA) ST/OODBMS User Group 1/17 meeting - VisualWave

12. comments on a presentation to TSUG (Toronto ST User Group)

 

 
Powered by phpBB® Forum Software