jyWebShell

After my efforts Friday to get jython working in swing, I set upon my real goal: HTTP/HTML access to a server-side jython session. The idea is that the jython session runs in the app-server container, and thus has access to the full runtime configuration and capability of the system. It is exposed to the user[s] … Continue reading “jyWebShell”

After my efforts Friday to get jython working in swing, I set upon my real goal: HTTP/HTML access to a server-side jython session. The idea is that the jython session runs in the app-server container, and thus has access to the full runtime configuration and capability of the system. It is exposed to the user[s] in a durable yet dynamic manner.

I’ve packaged up the results as jyWebShell 1.0. At 5MB, it’s a bit larger than a traditional .war file since it contains the full Jetty distribution, as well as Struts and jython.

I use the XMLHttpRequest object in the UI, which submits just the current python command, and updates the page in-place with the result of that evaluation; however, if the XMLHttpRequest doesn’t exist, a normal POST is done, and will work just fine.

I’ve also got a short Flash demo [read: “screencast”] of it in action; no audio, unfortunately … a project for another weekend.

allowing trackback

I’m now allowing trackback by default on new posts. Since this (and syndication-feed generation) was my original motivation for moving to MT (vs. a homebrew/ad-hoc setup), I feel kinda silly. In my defense, I know what “ping” is, and it’s not “trackback”. Now I know what “moveabletype:ping” means, too. :p

I’m now allowing trackback by default on new posts. Since this (and syndication-feed generation) was my original motivation for moving to MT (vs. a homebrew/ad-hoc setup), I feel kinda silly. In my defense, I know what “ping” is, and it’s not “trackback”. Now I know what “moveabletype:ping” means, too. :p

REST Design questions 2 and 3

Dave Megginson continues with his REST design questions. Herein, I respond: Question #2 … Yup, I’ve used query-paramaters in the way you describe to paramaterize a large resource space. I don’t consider it particular inelegant or ugly, but maybe that’s a matter of perspective… I believe that retrieving the “container” resource should respond with a … Continue reading “REST Design questions 2 and 3”

Dave Megginson continues with his REST design questions. Herein, I respond:

Question #2

Yup, I’ve used query-paramaters in the way you describe to paramaterize a large resource space. I don’t consider it particular inelegant or ugly, but maybe that’s a matter of perspective…

I believe that retrieving the “container” resource should respond with a form, indicating something like … “the resource is large, and supports paging, and the following values can be used to paramaterize the resource-space: * offset:non-negative integer * count:bounded integer:0..50 * sortCode:enumeration{ * ‘name’: ”’sort on object’s name”’ * ‘size’: ‘sort on object’s size’ * …} * sortAscending:boolean “

As HTML has its forms, we probably want media-types tailored to machines … either a new level of user-agent mediating for the user, or an autonomous one.

One of the more annoying issues I’ve run into with this is documentation of the cross-parameter interaction of complex query-spaces. Once things become a flattened name-value-pair list, I don’t believe you actually lose representational complexity (vs. submitting, say, a QueryParam struct on a more traditional procedural API), but you definitely lose representational ease. You may have to do things like lexically-structure your paramater-names, or disambiguate them. That bit is pretty inelegant, true.

Question #3

Links means whatever is specified by the format defining the context in which link appears. For instance, html:a@hrefroughly means “this is the the location that should be travesed to in the user agent when the contained object is clicked on”, or something. In the @xmlns case, yes, it does not mean what html:a@href means, but why should it?

And, yes, while the URIs which are used for most xmlnses don’t resolve, this is a bad thing, specifically for the reasons you’re getting at — HTTP URLs should resolve. This is especially true for namespaces, IMHO, because more often than not the semantics are implicit and unknown, unlike HTML where it’s expliclit and well-known.

Yes, there’s some nice ideal world where a spider can simply GET deeper and deeper into information resources. And in a RESTful web, that may even be very true. But it’s a bit naive to believe that at some depth the crawler doesn’t need to understand a least a bit of the document semantics — in fact, an important part of Fielding’s dissertation is that the HTML semantics are wide-spread and well-known.

simple swing jython shell

Today I created a little swing GUI shell to provide an interactive session with a Jython interpreter. It comprises two text areas — a larger area at the top for output, and a smaller text area at the bottom for input. It is not line-level interactive, as the normal console shell is; instead, you submit … Continue reading “simple swing jython shell”

Today I created a little swing GUI shell to provide an interactive session with a Jython interpreter. It comprises two text areas — a larger area at the top for output, and a smaller text area at the bottom for input. It is not line-level interactive, as the normal console shell is; instead, you submit complete expressions with Ctrl-ENTER.

There’s a bit of trick in there about two different methods on the PythonInterpreter API: exec and eval. Digging through the sources of the provided interpreters, I came up with the following, which seems to work well:

cmd = input.getText(); output.write( “>>> ” + cmd + “\n” ); try { res = interp.eval( cmd ); output.write( res.toString() + “\n” ); } catch ( PyException exec ) { if ( Py.matchException( exec, Py.SyntaxError ) ) { try { interp.exec( cmd ); } catch ( PyException exec2 ) { output.write( exec2.toString() ); //exec2.printStackTrace( new PrintWriter(output) ); } } else { output.write( exec.toString() ); //exec.printStackTrace( new PrintWriter( output ) ); } }

Here is the whole swing jython interpreter shell program; compiled against Jython 2.1,

Re: REST Design Questions

Dave Megginson has posted some questions about his understanding of REST. First off, please do look beyond the “there are only 4 [HTTP] verbs” aspect of REST. “Hypermedia as the engine of application state” is hand-in-hand with Constrained Interface as being fundamental to the RESTful web. As well, the GET/POST distinction is critically more important … Continue reading “Re: REST Design Questions”

Dave Megginson has posted some questions about his understanding of REST.

First off, please do look beyond the “there are only 4 [HTTP] verbs” aspect of REST. “Hypermedia as the engine of application state” is hand-in-hand with Constrained Interface as being fundamental to the RESTful web. As well, the GET/POST distinction is critically more important than any other aspect of constrained interface, I believe.

Back to question 1 … yes, the identifier does need to be recorded. This is the client’s responsibility, though a good server would help. That is: if the usage of the protocol is embracing REST, then each message would already come back with the identifier of the resource baked in. In any case, I think there’s a fallacy that the resource representation alone is or should be solely sufficient to describe the resource … if that was the case, why does HTTP need headers at all!? Certainly, there is meta-data that the client must be responsible for.

On the client side, I think your options are: keep the data external to the representation, or keep it within the representation. Since you’re assuming XML documents, I recommend that you use it’s extensibility, maybe via a namespaced attribute on the root level. How about thisDocumentWasHttpRetreived:from="http://.../", or maybe rdf:about?. I’ve also used [eg:]href, which works well; you may like xlink:href, though.

Regarding identifiers and locations … it’s nice to know the identitiy of things; it’s also nice to have locations of things. But it’s really nice when your Uniform Resource {Identification,Location} scheme supports redirection, such as HTTP[s] does.

Amazon’s RESTless WS API

Steve Maine’s Isomorphism post is really good until the end, where he tries to make a point about Amazon.com’s “touted” RESTful web service API. The REST crowd touts Amazon’s human-focusedservice as a REST example, not the WS API. Only Amazon themselves claim that their non-SOAP API is RESTful, and I believe it’s because they’re confused. … Continue reading “Amazon’s RESTless WS API”

Steve Maine’s Isomorphism post is really good until the end, where he tries to make a point about Amazon.com’s “touted” RESTful web service API.

The REST crowd touts Amazon’s human-focusedservice as a REST example, not the WS API.

Only Amazon themselves claim that their non-SOAP API is RESTful, and I believe it’s because they’re confused. As well, there’s not a marketing term for “simply using HTTP query strings to invoke RPC which returns XML without doing SOAP or XML/RPC”. Thus, everyone calls it REST, even though it isn’t, necessarily.

So, the reason that <wsa:Action>urn:GetCart</wsa:Action> and http://webservices.amazon.com/onca/xml?Operation=CartGet[...] are isomorphic is because they trivially are. They’re both RPC.

Re-creating the same thing in a purely RESTful way would not look isomorphic, depending on how much of HTTP you want to exploit. I’ll leave that as an exercise for the reader, for the moment. As well, Joe Gregorio has been developing that idea out.

mead and ESB

On the new-year’s eve, Odd and I brewed a mead. We’ll likely try some over the summer, but for the real spoils we will wait until the new year’s eve next, when we will enjoy it fully while brewing another batch. More recently, I’ve used the London Ale liquid yeast I received for Chistmas to … Continue reading “mead and ESB”

On the new-year’s eve, Odd and I brewed a mead. We’ll likely try some over the summer, but for the real spoils we will wait until the new year’s eve next, when we will enjoy it fully while brewing another batch.

More recently, I’ve used the London Ale liquid yeast I received for Chistmas to brew an ESB. I took the recipe – as I did for Ale Hallow’s Eve – from looking at a bunch of recipes and averaging a few together. I tried some while racking it over into a carboy, and it’s quite good! Better than most of the brews I’ve done so far … I attribute that primarily to the liquid yeast. I’m next going to do a bock or dopplebock with the other liquid yeast I got for Christmas; if there’s as-noticeable a quality improvement, I might not go back.

Anyways, since I still haven’t created a better publishing framework for these little structured-data tidbits, yet … and against all sense since it’s not even appropriate mime-typed, let alone easily seperable from the page-content or GRDDL’ed or anything …. here’s the data for both the mead and the ESB:

@prefix : http://asynchronous.org/ns/2004/homebrewing#. @prefix hb: :. @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#. @prefix rdfs: http://www.w3.org/2000/01/rdf-schema#. @prefix foaf: http://xmlns.com/foaf/0.1/. @prefix dc: http://purl.org/dc/elements/1.1/. @prefix xsd: http://www.w3.org/2001/XMLSchema#. @prefix cc: http://web.resource.org/cc/.

<#jsled> a foaf:Person ; foaf:nick “jsled” ; rdfs:seeAlso http://asynchronous.org/jsled/foaf .

<#newYearsGingerMead> a hb:Recipe ; rdf:label “A ginger mead recipe based on Papazian.” ; hb:derivativeOf <#papazian_melimigueleniumGingerMead> ; foaf:maker <#jsled> ; hb:ingredient [ :amt [ rdf:value 15; hb:units “lbs” ]; rdf:label “local honey, clover” ] ,[ :amt [ rdf:value 0.5; hb:units “lbs” ]; rdf:label “grated ginger root” ] ,[ :amt [ rdf:value 2 ]; rdf:label “Red Star champagne yeast [yellow packet].” ] .

<#newYearsMead2004_5> a hb:BrewInstance ; hb:recipe <#newYearsGingerMead> ; dc:created “2004-12-31-05:00″^^xsd:date ; foaf:maker <#jsled>, <#oddmonster> ; hb:journal [ dc:created “2004-12-31-05:00″^^xsd:date; rdfs:label “OG 1.094 @~70 deg F; very sugary, very tasty!” ] ,[ dc:created “2005-01-06-05:00″^^xsd:date; rdfs:label “has been bubbling quite consistently every few seconds for days, now. No significant fermentation spike.” ] ,[ dc:created “2005-01-10-05:00″^^xsd:date; rdfs:label “bloop’ing every ~10 seconds at 2-ripples-full” ] .

<#averagedEsb> a hb:Recipe ; rdf:label “A basic ESB recipe.” ; dc:created “2005-01-10-05:00″^^xsd:date ; foaf:maker <#jsled> ; hb:ingredient [ :amt [ rdf:value 4; hb:units “lbs” ]; rdf:label “light extract” ] ,[ :amt [ rdf:value 3; hb:units “lbs” ]; rdf:label “amber extract” ] ,[ :amt [ rdf:value 1; hb:units “lbs” ]; rdf:label “local honey, clover” ] ,[ :amt [ rdf:value 2; hb:units “oz” ]; rdf:label “Fuggles @ 60 min” ] ,[ :amt [ rdf:value 1.5; hb:units “oz” ]; rdf:label “Fuggles @ 15 min” ] ,[ :amt [ rdf:value 0.5; hb:units “oz” ]; rdf:label “Fuggles @ 3 min” ] ,[ :amt [ rdf:value 2; hb:units “tsp” ]; rdf:label “gypsum” ] ,[ :amt [ rdf:value 1 ]; rdf:label “ale yeast” ] .

<#averagedEsb2005> a hb:BrewInstance ; hb:recipe <#averagedEsb> ; dc:created “2005-01-27T19:11:00-05:00″^^xsd:dateTime ; foaf:maker <#jsled> ; hb:journal [ dc:created “2005-01-10-05:00″^^xsd:date; rdf:label “Used liquid Wyeast 1968 from Nov 2004, incubated 2 days. OG: 1.056 @ 60 deg F.” ] ,[ dc:created “2005-01-22-05:00″^^xsd:date; rdf:label “racked to glass carboy; FG: 0.016 @ 60 deg F; tastes good, though still a bit sharp. The hops didn’t come throuhg nearly as strongly as expected. I’m looking forward to more maturation.” ] .

Winooski, VT water mineral content / analysis

When brewing beer, certain styles are partially characterized by the water quality. Since beer is some 90% water, it’s composition can weigh heavily on the output. As well certain styles have come to be popular or even viable because of historical local ground-water conditions; particular English bitter institutions such as Bass are that way because … Continue reading “Winooski, VT water mineral content / analysis”

When brewing beer, certain styles are partially characterized by the water quality. Since beer is some 90% water, it’s composition can weigh heavily on the output. As well certain styles have come to be popular or even viable because of historical local ground-water conditions; particular English bitter institutions such as Bass are that way because of the super-hard water of Burton-on-Trent … Czech pilsners aren’t the same unless they’re devoid of minerals, as the groundwater of Pilzen is.

Thus, it’s useful to get an anlysis of ones ground water if you’re trying to brew certain styles; this may be posted on-line if we were in Palo Alto or San Francisco, but the Winooski water dept. has some catching up to do.

In any case, this is as of 2003, I believe, so it should still be basically valid for a few years:

  • Calcium as CaCO3 (Calcium Carbonate): 45 ppm
  • Chloride: 17 ppm
  • Iron: < 0.01 pm
  • Manganese: 0.007-0.012 ppm
  • Sodium: 7.5 ppm
  • Potassium: 1.31 ppm
  • Sulfate: 15 ppm
  • Silica: 1.4 ppm
  • Silicon: 0.67 ppm

LML and RX

Last weekend I got to thinking about alternative representations for RDF in XML, inspired by Bill de hÓra’s LML format. Over the course of this week, there was some discussion on www-rdf-interest that prompted me to think through some of the details. This weekend, I wrote up what I was thinking a bit more specifically. … Continue reading “LML and RX”

Last weekend I got to thinking about alternative representations for RDF in XML, inspired by Bill de hÓra’s LML format.

Over the course of this week, there was some discussion on www-rdf-interest that prompted me to think through some of the details.

This weekend, I wrote up what I was thinking a bit more specifically. The result is a format for RDF in XML called Rx. It’s basically an unstriped syntax for RDF in XML which maps RDF Properties to XML elements, with RDF/XML’s parseType="Resource" the default.

Coming full circle, I can now re-express LML in RX, in order to get an idea of how different it is from Bill’s pure-XML syntax.

The major difference compared to Bill’s format is the moving of data out of attributes an into XML elements. RX just doesn’t allow it, since it’s yet another option for serialization that it is possible to do away with.

In any case, here’s the same LML example from last week, but in RX:

001 Bill de hora jsled rdf http://www.w3.org/RDF/ markup http://www.w3.org/XML/ 2005-01-08T10:57-0500 2005-01-08T10:57-0500 http://asynchronous.org/ns/lml yes original post http://www.dehora.net/journal/2005/01/lmllistmarkuplanguage.html Danny’s response http://dannyayers.com/archives/2005/01/08/list-markup-language/ followup to Danny http://www.dehora.net/journal/2005/01/dataabovethelevelofasinglesite.html

SOA and web services

The following is a message to the service-orientated-architecture yahoo group. It’s in response to a thread about standardized interfaces and protocol semantics. I don’t think it bring anything new to the table except my own understanding of some issues, but – especially since Yahoo Group’s search interface is so bad – I’m going to post … Continue reading “SOA and web services”

The following is a message to the service-orientated-architecture yahoo group. It’s in response to a thread about standardized interfaces and protocol semantics. I don’t think it bring anything new to the table except my own understanding of some issues, but – especially since Yahoo Group’s search interface is so bad – I’m going to post it here in case other people find it useful.

On Mon, 2005-01-10 at 19:14, Spork, Murray wrote:

Should we add new verbs that incorporate (for example) complex transactional semantics – or should we instead refine the current verbs through other mechanisms. For example – by layering other protocols on top of HTTP. If we do the later then I strongly agree with Mark – the semantics of the verbs in the higher level protocol should not contradict the verbs in HTTP.

Yes.

I think what is happening here is that the HTTP verbs are being implicitly refined by attaching some semantic behavior to the resource – in this case the verb PUT is refined by stating that a particular resource is of type “order-acceptor” – in this way a client (that understands what an order-acceptor is) can infer that PUTing an order to this resource will cause a order to be placed.

IMO verbs are all about defining side-effects.

Yes. The hard assurances, side-effects and basic semantics are defined by the verbs, and refined, as well as contextualized, by the type of the data being operated over.

It seems like all the effort that’s gone into WS-* in the last few years could have instead been directed at determining new verbs, collections of verb-profiles and more-rich media-types. Somehow, a lot of MEPs and the yet-another-RPC mechanism doesn’t seem as useful… I’m not exactly sure why not, though.

nor that HTTP is sufficiently flexible for allowing the incorporation of new verbs.

Hmm… is it even possible to have a protocol that both specifies operational semantics and does not do so … and still be efficient?

I’m not sure I understand your question – could you elaborate?

Not well enough, as it’s a poorly formed quesiton: “efficient” is too loose and relative of a word. But that won’t stop me from trying :) …

Especially for the “does not do so” part, I guess I’m thinking of a protocol whereby the operation isn’t specified, so much as the semantics of the unspecified operation being performed. I guess somewhere between HTTP and RPC; one would make an request^Winvocation of the form:

[ a :Invocation ; :informativeOperationName “get” ; :idempotent “true” ; :safe “true” ; :cacheControl [ :cacheable “true” ; :cacheStateTag “12345” ; :expirationDate “2005.01.12T10:19:00Z” ] ].

[For the “specifies” part I was thinking of something like HTTP, where the above properties for a handful of operations are specified in the … uh … specification. But that’s not important once you have the above.]

But what I’ve specifed is basically what’s become of SOAP and WS-*, except that — for the most part — the transfer semantics aren’t explicitly specified in the content of the messages, but are implicit in the namespaces and qualified-names present in the data being exchanged.

I guess that it is the obvious and direct consequence of the implementation of SOAP’s design… the quest for “protocol independence” leads to trivial use of a transport protocol that is basically: open connection and execute “Process Message”. Since all the semantics are defined in the data, there is no need for protocol-level verbs. As well, it actively seeks to ignore the semantics defined by any protcol it “rides”. Thus, an application protocol like HTTP is converted into transport.

As well, answers about “efficiency” are now more clear…

  1. no, it can’t be as efficient (as HTTP), since intermediateries need to do message inspection. A lot of message inspection.

  2. as well, it’s hard to see how one even describes the full semantics of these messages in a machine-processable way…

  3. but, it can be quite flexible, which further reduces intermediateries capabilities.

  4. the underlying protocol must be completely ignored to prevent conflict with higher-level semantics.

It continues to sound nothing like the web. I guess it could be used to implement services.