WebDAV interface design for launching, browsing, debugging, workspaces

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

WebDAV interface design for launching, browsing, debugging, workspaces

ccrraaiigg

Hi--

     Here's a WebDAV interface design for launching systems, browsing
classes, debugging processes, and exploring in workspaces[1]. This
provides control over Smalltalk systems from a text editor, and
underlies the Context[2] web console.

     Thanks in advance for comments.


-C

[1] http://tinyurl.com/l3t47gm (thiscontext.com)
[2] https://github.com/ccrraaiigg/context

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV interface design for launching, browsing, debugging, workspaces

timrowledge

On 22-12-2014, at 1:55 PM, Craig Latta <[hidden email]> wrote:
> [2] https://github.com/ccrraaiigg/context

Unfortunately when I download the zip (which is the only way to download the working app that I can spot right now) and unzip it I get an OS X notifier saying -

“context 4 alpha 1” is damaged and can’t be opened. You should move it to the Trash.

Which isn’t terribly helpful.

Is there another way to download I should use?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Science adjusts its views based on what is observed. Faith denies observation so belief can be preserved


Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

ccrraaiigg

Hi Tim--

> Unfortunately when I download the zip (which is the only way to
> download the working app that I can spot right now) and unzip it I
> get an OS X notifier...

     This is a known conflict between the way GitHub makes ZIP archives
and the Apple signing facility. There's an open issue for it in the
Context repo. I suspect I can avoid the notifier by just not signing the
repo at all; I'll try that soon.

     In the meantime, you can turn off the Gatekeeper facility in your
Security settings.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

timrowledge

On 22-12-2014, at 4:01 PM, Craig Latta <[hidden email]> wrote:

>
> Hi Tim--
>
>> Unfortunately when I download the zip (which is the only way to
>> download the working app that I can spot right now) and unzip it I
>> get an OS X notifier...
>
>     This is a known conflict between the way GitHub makes ZIP archives
> and the Apple signing facility. There's an open issue for it in the
> Context repo. I suspect I can avoid the notifier by just not signing the
> repo at all; I'll try that soon.
>
>     In the meantime, you can turn off the Gatekeeper facility in your
> Security settings.

OK, that lets *something* start up. What next? I’ve tried http://localhost:8090/memories/23687C16-EBB8-48B7-A38D-1B8D9216865B/session/state, for example, and it shows nothing in Safari.
For those of us that have no clue, some guidance on how to do anything with it would be great.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Science adjusts its views based on what is observed. Faith denies observation so belief can be preserved


Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

Chris Cunnington-4

> On Dec 22, 2014, at 7:17 PM, tim Rowledge <[hidden email]> wrote:
>
>
> On 22-12-2014, at 4:01 PM, Craig Latta <[hidden email]> wrote:
>
>>
>> Hi Tim--
>>
>>> Unfortunately when I download the zip (which is the only way to
>>> download the working app that I can spot right now) and unzip it I
>>> get an OS X notifier...
>>
>>    This is a known conflict between the way GitHub makes ZIP archives
>> and the Apple signing facility. There's an open issue for it in the
>> Context repo. I suspect I can avoid the notifier by just not signing the
>> repo at all; I'll try that soon.
>>
>>    In the meantime, you can turn off the Gatekeeper facility in your
>> Security settings.
>
> OK, that lets *something* start up. What next? I’ve tried http://localhost:8090/memories/23687C16-EBB8-48B7-A38D-1B8D9216865B/session/state, for example, and it shows nothing in Safari.
> For those of us that have no clue, some guidance on how to do anything with it would be great.

*sigh* I promised myself I wouldn’t get involved…here we go.

First off, the things Craig does are remarkable. The second thing is if there was a prize for obfuscation of what it he does, he’d win a prize.

Let’s say Spoon has only three players: a client; a server; and a the page you see in a browser. It’s the exact same rig as a client/server/web page experience on the web. Three players.

What you see first, the web page, is almost irrelevant to understanding Spoon. What you’ve seen so far? Forget it. What you want to see is the client image.

See, Spoon is about having a client image provide tools that remotely operate on a server image, a smaller image, called the ‘history' image. All the tooling of the history image is remote for the simple reason that there are no tools, class names, or characters in the history image. It’s a pure, pure, pure object environment. No dead text which is bad, bad, bad.

So, the place to start with is the client image, the one with the tools. Execute your own version of this in a Mac Terminal.

/Users/chriscunnington/Desktop/context-master/context\ 4\ alpha\ 1.app/Contents/Resources/context\ 4\ alpha\ 1\ processor.app/Contents/MacOS/Spoon\ VM\ Opt /Users/chriscunnington/Desktop/context-master/context\ 4\ alpha\ 1.app/Contents/Resources/context\ 4\ alpha\ 1\ processor.app/Contents/Resources/context/memories/23687C16-EBB8-48B7-A38D-1B8D9216865B/23687C16-EBB8-48B7-A38D-1B8D9216865B.image &

What you’re looking at is not one Apple application, .app file, but two. The images that matter are super buried in a directory called ‘memories'. To no help at all, they have not names, but UUIDs. This is where you need to start.

Execute the above and you get an image. The master control panel. Got that? Good.

Now look for a closed window called ‘remote messaging’. Open that. This is where the Spoon explanation should start. Full stop.
Those commands allow you to start the Flow/socket/remote messaging relationship with the history memory found here:

Users/chriscunnington/Desktop/context-master/context\ 4\ alpha\ 1.app/Contents/Resources/context\ 4\ alpha\ 1\ processor.app/Contents/Resources/context/memories/946BE974-48B7-4D11-B209-6355B3E49722

Buried. Do I lie?

It’s the history memory that you start with that AppleScript script found here:

Macintosh-6:~ chriscunnington$ /Users/chriscunnington/Desktop/context-master/context\ 4\ alpha\ 1.app/Contents/Resources/Scripts/main.scpt

which starts automatically when you double click on 'context 4 alpha 1.app'. (And remember that’s just the first *.app file. The one inside that one has the UUID named memories. It is called 'context 4 alpha 1 processor.app')

That image, the history image, has a server in it that is serving the page you are lead to look at first. Really, you should look at it last. It’s like looking at the Transcript and wondering where the Workspace is.

See, you use the remote tools to code the smaller, remote image, so it can server a webpage, which is the first thing you see. And should actually be the last.

Take my advice, execute the longest path above, the first one I showed you. Then open the ‘remote messaging’ window. I made that window start the remote memory in 2011. I haven’t been able to do that this time around.

Look at the buttons on the top edge of the client image that say things like: start history; remote browser; save history; quit history; ping history. You’ll start to get the big picture. 1) Connect to the history image. 2) Open ‘Remote Browser’. 3) Hack the small image that serves a web page.

Chris



>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Science adjusts its views based on what is observed. Faith denies observation so belief can be preserved
>
>


Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

ccrraaiigg
In reply to this post by timrowledge

Hi--

     Tim writes:

> For those of us that have no clue, some guidance on how to do
> anything with it would be great.

     While Context is in alpha, stuff will be missing, especially
instructions. If you ever get confused about something, please create an
issue about it in the Context repo[1]. You can also chat in real time
with Context developers[2].

     In particular, the implementation of this design is not finished.
I'd like to get feedback on the design.

     Chris Cunnington writes:

> ...if there was a prize for obfuscation of what it is [Craig] does,
> he’d win a prize.

     Yikes, I certainly don't mean to obfuscate anything. I don't think
Tim was confused about the theory of operation; hopefully the blog post
he read explained it. Again, if you're ever confused about something in
Context, please create an issue about it, and drop by [2] for a chat. I
correct some misinterpretations below.

> What you see first, the web page, is almost irrelevant to
> understanding Spoon. What you’ve seen so far? Forget it.

     No, the console welcome page gives a high-level introduction to
what Context and Smalltalk are. It's completely relevant.

> [Context] is about having a client image provide tools that remotely
> operate on a server [memory], a smaller [memory], called the
> ‘history' [memory].

     No, the history memory records the history of edits made to a
subject memory (where you do normal development). It takes the place of
the changes and sources files of a traditional Smalltalk system. Remote
operation can happen between any two systems. The history memory happens
to be headless, but one wouldn't normally browse its classes. It just
sits in the background recording what you do, and answering
history-related queries from the subject. It's an application-specific
object database, where the application is recording history.

> What you’re looking at is not one Apple application, .app file, but
> two.

     (The outer app starts the console webserver and a host web browser
to view it. The inner app is the normal Squeak app.)

> The images that matter are super buried...

     The point of the console is to provide an easy way to list, start,
and stop memories, and avoid having to dig through the app folder at
all. The structure of the app folder is a composite of three sets of
host platform packaging constraints, so it is inevitably complex.

> To no help at all, they have not names, but UUIDs.

     By using the console, the user doesn't need to care what the
snapshot filenames are, or even that snapshots are stored in files at
all. Each memory can have whatever user-friendly names you like; the
console welcome page lists them, along with the services the memory
provides.

> This is where you need to start.

     No, you need to start at the console, and if something is confusing
and/or doesn't work as you expect, you need to create an issue for it
and have a chat with us at [2]. :)

> Execute the above and you get [memory
> 23687C16-EBB8-48B7-A38D-1B8D9216865B]. The master control panel.

     No, that's merely a Squeak 4.5 memory that has remote messaging
support installed. What it can do (remote class browsing, remote process
browsing, get history recording service from a history memory) are
things any memory with that support installed can do. It's not special.
The console website is the master control panel.

> ...[memory 946BE974-48B7-4D11-B209-6355B3E49722], the history
> [memory], has a server in it that is serving the page you are lead to
> look at first.

     Memory 946BE974-48B7-4D11-B209-6355B3E49722 isn't meant to record
history for anyone, nor is it meant to be hacked on. It's only meant to
run the console.

     It sounds to me like you're complaining that the software is alpha,
rather than about the design of the console. It seems you're unwilling
to evaluate the design of the console until the implementation is
finished. If you insist on that, you probably want to wait until Context
is beta before thinking about it. But I hope you change your mind!


     thanks again,

-C

[1] https://github.com/ccrraaiigg/context/issues
[2] http://squeak.slack.com (channel #context)

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

ccrraaiigg

     Oh, and the memory snapshot filenames are UUIDs so that they can be
trivially unique and be computed without user interaction (users are
free to assign as many other names as they wish to each memory, but they
are independent of the snapshot filename). Each system uses its UUID to
derive the port number on which it opens its remote messaging server.
Context has an algorithm for converting a UUID to a port number.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV interface design for launching, browsing, debugging, workspaces

Bert Freudenberg
In reply to this post by ccrraaiigg
On 22.12.2014, at 22:55, Craig Latta <[hidden email]> wrote:
> Hi--
>
>     Here's a WebDAV interface design for launching systems, browsing
> classes, debugging processes, and exploring in workspaces[1]

By "design", do you mean as an idea, or is it actually supposed to be working right now?

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

ccrraaiigg

Hi Bert--

> By "design", do you mean as an idea, or is it actually supposed to be
> working right now?

     An idea. Isn't that what people usually mean by "design"?


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

timrowledge

On 23-12-2014, at 9:41 AM, Craig Latta <[hidden email]> wrote:

>
> Hi Bert--
>
>> By "design", do you mean as an idea, or is it actually supposed to be
>> working right now?
>
>     An idea. Isn't that what people usually mean by "design”?

It’s one of those words that has become so corrupted by general usage (like ‘engineer’) that it could mean almost anything. A train driver is not an engineer. A plumber in not a ‘sanitary engineer’. The insane renderings on yankodesign are not designs.

Anyway, my problem was simply that I saw nothing the let me work out what to do once we got past the ‘turning off gatekeeper’ part. And I already know a modicum about Spoon from having discussed it with Craig for… a long time, actually. (And, way to go Apple, with a meaningless and confusing error message)

Once it started up I got a web page on a server running on localhost. OK, fair enough, that suggests there may be links to follow. Hmm, just one, for a long uuid. Try that. Nothing… literally, a blank page.

Try adding various terms to the end of the url as implide by the text - ‘workspaces’, ‘session/state’ etc. Nothing. I see stuff about mounting webdav in a text editor… no idea what that might men. I’ve read ‘webdav’ but I’ve never knowingly had anything to do with it. There’s probably a very simple explanation that would sort all this out and could be added to the root page presented when opening the app.

Oh, and an explanation of how to shut it down politely would be nice, too. WIth no visible dock icon I had to resort to Activity Monitor to find the process and force quit.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If only people came with pull-down menus and online help.



Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

Bert Freudenberg
In reply to this post by ccrraaiigg
On 23.12.2014, at 18:41, Craig Latta <[hidden email]> wrote:
> Hi Bert--
>
>> By "design", do you mean as an idea, or is it actually supposed to be
>> working right now?
>
>     An idea. Isn't that what people usually mean by "design"?

It does not rule out a working prototype, that's why I asked. Much of your writing sounds like this actually existed. "Here’s a typical filesystem layout" sounds very different than "Here’s how a filesystem layout could look like".

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

ccrraaiigg

     Tim, Bert: apparently you have read the description. What do you
think of it?


     thanks,

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: WebDAV interface design for launching, browsing, debugging, workspaces

Bert Freudenberg
On 23.12.2014, at 22:33, Craig Latta <[hidden email]> wrote:
>
>     Tim, Bert: apparently you have read the description. What do you
> think of it?

I like the Linux procfs as a low-level way to find out details about a process. Having something similar for a Smalltalk image sounds cool, but I'm not yet sure how much value this adds over a repl. I'd like to try it :)

- Bert -






smime.p7s (5K) Download Attachment