I don't have editing Text classes, per se, as a goal. I think I prefer
restricting myself to strings + conventions, so that the data can be
more human readable even in it's stored form, and easier to transfer
between mediums. For example todays private information might become
public, at which point I want to be able to move it to a regular Swiki,
without assuming a Squeak client for all viewers.

So I think what is stored should be strings, though Text might be a good
GUI element - making links work, showing emphasis, so forth.

I agree about wanting to be able to edit existing swikis, and looked
into Scamper for this, but the mess that is HTTPSocket repels me at the
moment. Specifically, I got bogged down because it/Scamper mixed up
local/relative/absolute addresses. Though it might be just my
inexperience with the HTTP stuff. Do you have code that uses HTTP to 
A. Read a swiki page
B. Request the markup version format for editing
C. Post modified markup version
?

I'm considering the "subvert the code model and use it for docs" route
Lex suggested for personal information, it is hard to beat for immediate
results. But it leaves the "recovery is inconvinient" issue, doesn't
help me edit public swikis, and is likely to feel like the hack it is...

Daniel

Brent Vukmer <bvukmer at blackboard.com> wrote:
> Daniel -
> 
> I haven't done any building, just thinking, so far.  What I'd *really*
> like, though, is to be able to use a Squiki -- pure-Text Swiki-like
> object within my image, re-using all the Text* classes -- to store
> notes. I would also like to be able to park a Squiki image on a server
> and edit it via HTTP GET and POST, where the payload is just the gzipped
> serialized SquikiPage. 
> 
> I'd also like to be able to edit Swiki pages "directly", as you said.
> We could enhance the Scamper package so that Scamper hides the
> complexity of editing a Swiki page, and/or enhance the Swiki package so
> that Swikis can accept a POST of serialized Text for a given page.