[AOLSERVER] "Fun, free applications for building personal sites."
Dossy Shiobara
haven't had the motivation to pursue. However, I really would like to
hear what folks think of his statement:
> What AOLServer "community" needs is a bunch of fun, free
> applications for building personal sites. It's stupid, but
> that's how you get the initial hook on people. I'm not sure who
> is going to make and release these "fun, free apps" though,
> because there's currently also no audience for it. It's kind of
> a bootstrapping problem.
It's definitely a chicken-and-egg problem: most newbies won't try
AOLserver "for the heck of it" but would go through the trouble if there
was an application they wanted to run, i.e. OpenACS.
Of course, there's little motivation to develop a fun, free app. for
AOLserver if nobody's going to try it out.
How do we break out of this deadlock?
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Alex
to some degree :)
Basing on my AOLServer experiences while making one of the
sites (www.tolk-i-polza.ru if you ask, but you got to learn Russian to use it)
I am trying to make a framework that might help newbies.
1) It shall be much easier to install, use and extend than OACS.
2) Automatically (or semi-automatically, and only on some platforms)
install aolserver and all needed components from source code.
3) Provide simple object-DB interface on top of ns_db , thus no SQL
knowledge will be required to start off.
4) Implement templating mechanism (hopefully, easy to use and transparent)
5) Provide all code needed for ready-to-use rudimentary site, to be
used as an example.
I am doing this mostly for myself, so I could more easily "seed" new
sites I am working on.
Especially when doing something relatively simple.
But if you think this might be worth sharing, I will be more than
happy to do that.
Thanks,
~ Alex.
Thorpe Mayes
for AOLServer.
It will not do anyone any good to have a fun, free application if they
cannot figure out how to install the software.
The documentation does not have to be absolutely comprehensive. How
about this:
how to do a basic install on linux (a couple of flavors) and Windows -
step-by-step instructions for the current version of AOLServer on
current operating systems.
a complete list of the variables in the nsd.tcl file and what they
mean and some typical values
a standard way to organize the files associated with AOLServer
an intro to building stuff in AOLServer with tcl
Before you jump start AOLServer with magic, make sure you have the
basics covered, otherwise, it will just be magic.
Thorpe
Just enough for someone to get the thing working without having to
feel like an idiot.
Thorpe Mayes
voice: (405) 514-9753
tma...@ecognizant.com
Matthew M. Burke
for me this summer on fixing up the nsgd module---pushing out a lot of
changes I've made that have never seen the light of day, adding some new
features, etc.
I mention this because I can think of several fun things to do with
AOLserver and a powerful, flexible graphics generator. But I don't want
to limit the fun to just me. If you have a good idea and would need a
particular feature in nsgd to enable it, let me and/or my student (also
named Matt) know.
I read this list regularly, and my student _should_ be doing so....
Matt
--
Matthew Burke
Assistant Professor of Computer Science
The George Washington University
mmb...@gwu.edu
202.994.0718
Jeff Rogers
> Back in Feburary 2005, Dan Chak at MIT said something to me that I just
> haven't had the motivation to pursue. However, I really would like to
> hear what folks think of his statement:
>
> > What AOLServer "community" needs is a bunch of fun, free
> > applications for building personal sites. It's stupid, but
> > that's how you get the initial hook on people. I'm not sure who
> > is going to make and release these "fun, free apps" though,
> > because there's currently also no audience for it. It's kind of
> > a bootstrapping problem.
>
> It's definitely a chicken-and-egg problem: most newbies won't try
> AOLserver "for the heck of it" but would go through the trouble if there
> was an application they wanted to run, i.e. OpenACS.
>
> Of course, there's little motivation to develop a fun, free app. for
> AOLserver if nobody's going to try it out.
>
> How do we break out of this deadlock?
Fun Free apps.
The hottest fun free apps currently are mashups and social networking
things. And all the data providers (i.e., facebook, flickr, twitter,
etc) have php and java client libraries (and occasionally a few others).
I don't think any of them have aoslerver/tcl libraries. That is
needed as an entrypoint.
One starting point I'd be willing to help on here is an openid client
(since I've already started work on it).
The more traditional personal apps - news/content pages, blog/message
board, etc - are still useful too. (and would be a reason for having an
openid server also :) Prior to Dossy's call to action on this, I was
thinking about starting just such a project for my own use (under the
working name ASblog - A Simple blog, or AolServer blog, then expanding
it to A Simple Site, but ASS site doesn't seem so catchy). OpenACS is
out there; it's a great system but it's a big system, not really the
ideal introduction.
There's another problem too - "free". Or at least, cheap. Not
aolserver or the apps themselves, but a place to run them. There are
lots of places where you can get php hosting for $5 a month (which
includes a bunch of stuff preinstalled, email, etc...). If you want to
host aolserver, the cheapest option I'm aware of is an unmanaged linux
vps for around $15/mo and *then* you need to set up everything yourself.
(and depending on the vps you might have memory issues) I guess this is
just part of that chicken and egg problem. Maybe just call it /bin/sh
(the "shell" of the egg... get it?)
Somewhat related to this last point is my current interest (and
frustration) in helping out small non-profits. I'd like to help out
some local groups (preschools, clubs) set up websites for things like
fund-raising, school supplies wishlists, news, and so forth; I'd like
to use the best technology available as a foundation (imho, aolserver
meets that criteria) but the hosting costs make it unattractive - the
difference between $60 a year and $180 a year (labor costs are donated
of course) is significant at this level. (I vaguely recall a story of
Philip Greenspun pitching aolserver/acs to some nonprofit with zero
software cost being a big selling point and being rebuffed because in
their multi-million dollar budget was already allocated plenty for
building completely new systems from scratch. This is a different
league I'm talking about. The entire IT budget is maybe a few hundred
dollars and most of that probably goes for printer ink.)
Which brings me back to something I've mentioned before, shared hosting.
AOLserver can do virtual hosts, but a little more framework would be
needed to realistically serve multiple independent sites from a single
installation. Nothing huge or insurmountable, just some isolation
between separate servers so someone doesn't accidentally (or
maliciously) overwrite someone else's data. Two quickies come to mind:
'ns_db gethandle' should not be able to get a handle from a different
virtual server (I don't know if it can now), and there should be a way
to run a safe interpreter and pass commands like 'open' to a setuid
ns_proxy. The 3.x era nsvhr/nsunix modules let you run an entire server
as a different user, but that would be even more memory-prohibitive.
(Before someone says "just use apache, it does all this well" my point
is that I don't want to use apache, I want to use aolserver because it's
better for applications, and if it's worse for addressable
practicalities when I'd like to address those practicalities and make it
better.)
-J
Tom Jackson
parts of a web page. You return either javascript, html or an xml document,
which is probably a worthless option.
Maybe I got this wrong, but AOLserver should be able to step into a mashup
instantly.
tom jackson
Jeff Rogers
> Wait, I thought mashups were simply http requests from javascript to update
> parts of a web page. You return either javascript, html or an xml document,
> which is probably a worthless option.
>
> Maybe I got this wrong, but AOLserver should be able to step into a mashup
> instantly.
What you describe is ajax ("asynchronous javascript with xml", although
it seems no one uses xml anymore) plus dhtml (dynamic html) and yes,
aolserver can certainly provide that without too much trouble.
Many (probably most) mashups make use of ajax also, but the mashup part
is that they take data from multiple sources - say, from google maps and
craigslist - and put it together in some novel new way. A mashup can be
done entirely or mostly on the client in javascript but a few things
like same-source security, data storage, and having to work entirely in
javascript within a browser make it convenient for the server to get
involved. Which is why there are the php client libraries I mentioned
for flickr, twitter, facebook, etc...
The wikipedia entry on mashups gives a better description (and
references!) than my blurb here:
http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29
Dave Bauer
Tom Jackson wrote:What you describe is ajax ("asynchronous javascript with xml", although it seems no one uses xml anymore) plus dhtml (dynamic html) and yes, aolserver can certainly provide that without too much trouble.
Wait, I thought mashups were simply http requests from javascript to update parts of a web page. You return either javascript, html or an xml document, which is probably a worthless option.
Maybe I got this wrong, but AOLserver should be able to step into a mashup instantly.
Many (probably most) mashups make use of ajax also, but the mashup part is that they take data from multiple sources - say, from google maps and craigslist - and put it together in some novel new way. A mashup can be done entirely or mostly on the client in javascript but a few things like same-source security, data storage, and having to work entirely in javascript within a browser make it convenient for the server to get involved. Which is why there are the php client libraries I mentioned for flickr, twitter, facebook, etc...
The wikipedia entry on mashups gives a better description (and references!) than my blurb here:
http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29
http://cvs.openacs.org/cvs/openacs-4/packages/facebook-api/
Dave
-J
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
--
Dave Bauer
da...@solutiongrove.com
http://www.solutiongrove.com
Tom Jackson
> The wikipedia entry on mashups gives a better description (and
> references!) than my blurb here:
>
> http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29
Right, there is nothing special about mashups. An AOLserver application could
instantly step in and provide services. It really has nothing to do with php,
or Java, that is actually the point of this Web 2.0 stuff, and web services
in general: language neutral. Of course, Tcl is a step ahead in this respect,
since it doesn't care much about types.
The main thing you need with a mashup is data. Without that, there is nothing
to mash.
tom jackson
Bas Scheffers
> The main thing you need with a mashup is data. Without that, there
> is nothing
> to mash.
XML implementation, though not sure about the ones in PHP, Perl, etc
which are also likely to be C based. (I am currently profiling and
optimizing a car rentals aggregator site, which does tons of XML
parsing and creating. Its all in Java and its not pretty; sooo slow
and with enormous RAM requirements)
Has anyone used TclSOAP? And compared it in performance to Java SOAP
clients?
Bas.
Rusty Brooks
times, though, I did extensive modifications trying to get it to work with various WSDL files and in general
it does not do a complete job, which is kind of frustrating, especially when integrating with web services
that have TONS of data types and commands. It kind of looked like that WSDL implementation just didn't
progress past a certain point. I might screw with it some time but at the moment I've got the manual soap
definitions done for the apps I need to support, so, it's not that pressing.
Tom Jackson
> On 06/05/2008, at 11:44 AM, Tom Jackson wrote:
> > The main thing you need with a mashup is data. Without that, there
> > is nothing
> > to mash.
>
> And much of that data is in XML and tdom runs rings around any Java
> XML implementation, though not sure about the ones in PHP, Perl, etc
> which are also likely to be C based. (I am currently profiling and
> optimizing a car rentals aggregator site, which does tons of XML
> parsing and creating. Its all in Java and its not pretty; sooo slow
> and with enormous RAM requirements)
>
> Has anyone used TclSOAP? And compared it in performance to Java SOAP
> clients?
Have you not used the twsdl/TWiST API? Sorry, only server at the moment,
although you can build a client with the API.
I have some benchmarks on AOLserver, for a simple service which uses all
layers, but doesn't hit a database, 300-350 requests/sec.
If you are doing document creation, you can do this pretty easily, you define
your XML-Schema type, and then you can create the type by just supplying
data.
Example Services:
Config files which create the above services:
http://junom.com/document/windows/TWiST/examples/
Current code:
http://junom.com/gitweb/gitweb.perl?p=twsdl.git;a=summary
tom jackson
Tom Jackson
If you guys are actually using WSDL, please look at tWSDL. It functions very
well as a server. But internally you can define/derive types as described in
the XML-Schema types/structures standards. Once defined, you can create and
validate types (including correct handling of min/maxOccurs, isnull, etc.)
tom jackson
Brett Schwarz
In addition there is Web Services for Tcl: http://members.cox.net/~gerald.lester/WebServicesForTcl.html
I have not used it at all, so I can't offer any opinion...however it does look like it uses tdom.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Tom Jackson
> I don't think TclSOAP uses tdom, does it? That might explain any speed
> problems.
>
> In addition there is Web Services for Tcl:
> http://members.cox.net/~gerald.lester/WebServicesForTcl.html
>
> I have not used it at all, so I can't offer any opinion...however it does
> look like it uses tdom.
Right Web Services for Tcl requires Tcl 8.5 and tclhttpd, it doesn't work with
AOLserver.
tom jackson
Stefan Sobernig
>>> In addition there is Web Services for Tcl:
>>> http://members.cox.net/~gerald.lester/WebServicesForTcl.html
>>>
>>> I have not used it at all, so I can't offer any opinion...however it does
>>> look like it uses tdom.
>>
>> Right Web Services for Tcl requires Tcl 8.5 and tclhttpd, it doesn't work with
>> AOLserver.
>
Besides, Web Services for Tcl is based upon the TclOO package by Donal
K. Fellows which is not (besides other issues) multi-threading/
AOLServer compatible (no serializer etc.)
You might want to check out xotcl-soap (xosoap) as well which comes as
OpenACS package: see http://alice.wu-wien.ac.at:8000/xorb-doc/
> I don't think TclSOAP uses tdom, does it? That might explain any speed problems.
Indeed, TclSOAP is built around TclDOM/TclXML and suggests one of the
two C-based DOM backends: http://wiki.tcl.tk/9098
>> Has anyone used TclSOAP? And compared it in performance to Java SOAP clients?
I do not have a direct comparison, but probably some rough benchmark:
http://www.extreme.indiana.edu/xgws/soap_bench/linux_loopback/index.html
(the accompanying paper is also a good introductory read)
Generally speaking, and according to the benchmark above, Java-based
environments (Axis 1.2 at that time) are (across all benchmark types)
less performant than c/c++ based ones (gSOAP), by factors of ~7
(latency) and 10-15+ (end-to-end roundtrip, i.e. including
de/marshalling, arrays of ints + strings). The picture certainly changed
since 2004 because parsing (streaming parsers) and optimisation
techniques (differential marshaling) gained momentum in Java-based
toolkits, but it shows a tendency. Besides, memory footprint is not
considered in the above benchmark which might be even more important
than processing time depending on your requirements.
We are currently working on a performance evaluation of xotcl-soap.
First, tentative results show that xotcl-soap settles in the inbetween
the two benchmark ends above, in the lower third of this range. But,
again, the test setting is not directly comparable. I will report back
if there is interest. Moreover, we work on optimisations (differential
marshaling using adp templating, for instance) that might promise
speed-ups by a factor of 10 in certain settings.
//stefan
--
Stefan Sobernig
Institute for Information Systems and New Media
Vienna University of Economics
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan....@wu-wien.ac.at <mailto:stefan....@wu-wien.ac.at>
`- s...@thinkersfoot.net <mailto:s...@thinkersfoot.net>
Brett Schwarz
>
> ----- Original Message ----
> From: Tom Jackson <t...@RMADILO.COM>
> To: AOLS...@LISTSERV.AOL.COM
> Sent: Monday, May 5, 2008 11:46:47 PM
> Subject: Re: [AOLSERVER] "Fun, free applications for building personal sites."
>
> > problems.
> >
> > http://members.cox.net/~gerald.lester/WebServicesForTcl.html
> >
> > I have not used it at all, so I can't offer any opinion...however it does
> > look like it uses tdom.
>
> Right Web Services for Tcl requires Tcl 8.5 and tclhttpd, it doesn't work with
> AOLserver.
Tcl 8.5 *or* the _dict (source, windows binary) extension for Tcl 8.4_
I can't imagine that it would take too much to make it work with aolserver...in fact I believe
the main author of that package is using aolserver now, but I'm not sure if he has ported this over to aolserver.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Brett Schwarz
> >>> http://members.cox.net/~gerald.lester/WebServicesForTcl.html
> >>>
> >>> I have not used it at all, so I can't offer any opinion...however it does
> >>> look like it uses tdom.
> >>
> >> Right Web Services for Tcl requires Tcl 8.5 and tclhttpd, it doesn't work with
> >> AOLserver.
> >
>
> K. Fellows which is not (besides other issues) multi-threading/
> AOLServer compatible (no serializer etc.)
>
huh? Where did you get that it is based on TclOO? TclOO isn't even out yet. And where did
you get that TclOO is not compatible with aolserver...just curious (I haven't tried it myself within aolserver). It should be thread safe, as far as I'm aware (although I don't believe it is fully implemented yet, so you never know).
Tom Jackson
> Besides, Web Services for Tcl is based upon the TclOO package by Donal
> K. Fellows which is not (besides other issues) multi-threading/
> AOLServer compatible (no serializer etc.)
Web Services for Tcl isn't based on TclOO and it doesn't have any issues with
multi-threading. The client works great. I have used it to test all of my
WSDL example services.
Here is an example of how to use it:
http://junom.com/document/windows/TWiST/WS::Client.TXT
I think I just used the ActiveTcl version of Tcl8.5.
I'm not sure what it means to not have a serializer. Once WS::Client gets the
WSDL file, you can create 'stubs' for each operation. Then you just feed it a
list (without the element names, just data). A 'dictionary' is returned,
which includes the element names (usually this could be fed directly to
[array create] for simple structures).
The problem with the WS::Server running with AOLserver is that it uses the
tclhttpd API for I/O (biggest problem), but also uses many tclhttpd'isms to
create web pages for documentation, etc.
tWSDL with the TWiST API has a very thin connection to AOLserver. The same
services, with the same TWiST configuration file can run under nstclsh,
tclsh, tcpserver or even using a shell pipeline. The tclsh version can run
using Tcl socket, or using Tcl Threads (recommended).
The tcpserver version is great during application development because
everything is sourced up from scratch for each request.
As a WSDL server, the best feature of tWSDL is that you can define and derive
types based upon the XML-Schema definitions, and you can validate documents
against the type. Once defined, types are easy to create by feeding the
type's 'new' API with a Tcl list (with no element info, just data).
I haven't found any other WSDL toolkit which can derive simple types from
XML-Schema types or easily create complexTypes where minOccurs > 1. With
tWSDL a single TWiST 'configuration' file completely defines the web service
interface, there is no hand writing WSDL files or hand coding type
validation, and your internal API remain independent of the external
operation interface.
tom jackson
Tom Jackson
> I haven't found any other WSDL toolkit which can derive simple types from
> XML-Schema types or easily create complexTypes where minOccurs > 1.
Oops, I meant to say maxOccurs > 1. XML-Schema structural type serialization
is complicated. To do it correctly you have to know minOccurs, maxOccurs, if
the element is nillable, the default value (for tcl, if the default is the
empty string), and of course the data being serialized.
Rusty Brooks
to make a client?
Rusty
Stefan Sobernig
>> K. Fellows which is not (besides other issues) multi-threading/
>> AOLServer compatible (no serializer etc.)
>>
>
> huh? Where did you get that it is based on TclOO? TclOO isn't even out yet.
My fault. The only and first time I stumbled over Gerald's "Web Services
for Tcl" was in Donal's tcl2007 presentation on TclOO*. Therefore, my
misunderstanding ...
> And where did
>> you get that TclOO is not compatible with aolserver...just curious (I haven't tried it myself within aolserver). It should be thread safe, as far as I'm aware (although I don't believe it is fully implemented yet, so you never know).
> I'm not sure what it means to not have a serializer.
Let me rephrase, it is not said that it is not compatible (nothing to do
with thread safety or anything in that direction), I am just saying that
it might need some integration work. By serialiser, I am referring to
the needed generation of the ns_ictl script in the aolserver driver
thread. But, it goes without saying, this is just one option ...
*
http://www.tcl.tk/community/tcl2007/proceedings/programmingtechniques/OOforTclFellows.pdf
--
Stefan Sobernig
Institute for Information Systems and New Media
Vienna University of Economics
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan....@wu-wien.ac.at <mailto:stefan....@wu-wien.ac.at>
`- s...@thinkersfoot.net <mailto:s...@thinkersfoot.net>
Tom Jackson
Yes, there is a start of a client, which downloads, and parses a WSDL file.
But there are so many poorly defined services, and so many options which you
could use in a web service, that it hasn't been a priority to create a
generic client.
Instead I'm leaning toward redefining an external service using the TWiST API,
and with tiny changes (like the URL of the original service), use a TWiST
server as a proxy for the external service.
In fact, this type of client already exists in TWiST which allows for testing
the service via a web interface.
( See the example operations at http://junom.com/ws/mywebservice/ )
The testing interface is just a web page with a simple form. When the form is
submitted, the values are translated into a client request, which is POSTed
back to the same server (a seperate request). The only change needed for a
proxy would be the external URL used for POSTing the request. Slowly this is
coming together in the <ws>client API (which will be similar to <ws>return ).
tom jackson
On Tuesday 06 May 2008 07:50, Rusty Brooks wrote:
> I don't need it as a server, I need it as a client. You mentioned
> something a bout being able to use the API to make a client?
Tom Jackson
> Let me rephrase, it is not said that it is not compatible (nothing to do
> with thread safety or anything in that direction), I am just saying that
> it might need some integration work. By serialiser, I am referring to
> the needed generation of the ns_ictl script in the aolserver driver
> thread. But, it goes without saying, this is just one option ...
Well, it would require something more like a major rewrite. It was written for
tclhttpd and the tclhttpd API are used for I/O. The service configuration
files are written for tclhttpd as well, so those would have to be modified.
But, it is a simple piece of software, only a few pages, just very brittle to
external details.
The client works great! I would recommend it as a first thing to try before
investigating anything else.
tom jackson
Stefan Sobernig
>> Let me rephrase, it is not said that it is not compatible (nothing to do
>> with thread safety or anything in that direction), I am just saying that
>> it might need some integration work. By serialiser, I am referring to
>> the needed generation of the ns_ictl script in the aolserver driver
>> thread. But, it goes without saying, this is just one option ...
>
> Well, it would require something more like a major rewrite.
MY rephrasing on integration relates to TclOO and Brett's:
> And where did
> you get that TclOO is not compatible with aolserver...just curious (I haven't tried it myself within aolserver).
... NOT "Web Services for Tcl" ... just to avoid misunderstandings ...
//stefan
--
Stefan Sobernig
Institute for Information Systems and New Media
Vienna University of Economics
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan....@wu-wien.ac.at <mailto:stefan....@wu-wien.ac.at>
`- s...@thinkersfoot.net <mailto:s...@thinkersfoot.net>
Tom Jackson
> Tom,
>
> >> Let me rephrase, it is not said that it is not compatible (nothing to do
> >> with thread safety or anything in that direction), I am just saying that
> >> it might need some integration work. By serialiser, I am referring to
> >> the needed generation of the ns_ictl script in the aolserver driver
> >> thread. But, it goes without saying, this is just one option ...
> >
> > Well, it would require something more like a major rewrite.
>
> MY rephrasing on integration relates to TclOO and Brett's:
> > And where did
> > you get that TclOO is not compatible with aolserver...just curious (I
> > haven't tried it myself within aolserver).
>
> ... NOT "Web Services for Tcl" ... just to avoid misunderstandings ...
Hmmm, why would using TclOO or any other Tcl code require doing anything with
the driver thread, or require using ns_ictl? I still don't get what a
serializer is.
Is this one of those object system 'isms?
tom jackson
Stefan Sobernig
>>I still don't get what a
>>> serializer is.
> Is this one of those object system 'isms?
Well, no ... it is not an *ism in the sense of "peculiar feature" of an
object-based/oriented system. Streaming an in-memory state into a set of
characters based on run-time introspection is not a trait of OO. But for
OO, take a look at:
http://www.riehle.org/computer-science/research/1996/plop-1996-serializer.html
>> Hmmm, why would using TclOO or any other Tcl code require doing anything with
>> the driver thread, or require using ns_ictl?
I assume that you are familiar AOLServer blueprinting mechanism? Tcl
introspection (info) is used to stream the state of the interpreter in
the driver/main thread of AOLServer to the connection/scheduler/...
threads (and beyond, if you take Zoran's tclthread extension into
account) early in their life-cycle. This happens in
init.tcl->_ns_savenamespaces and helpers. So, in AOLServer Tcl's info +
_ns_* family of procs + Tcl's eval represent a procedural serializer.
But, as Tcl's info cannot introspect on the XOTcl/TclOO object system,
these object systems need to provide their own facility to re-create the
object graph (objects + relations) in terms of a script. Take a look at
generic/aol-xotcl.tcl in the XOTcl source distribution, it amends
standard _ns_savenamespace by a call to the xotcl Serializer object.
So, unless you don't want to call "package req" on XOTcl/TclOO in each
connection thread interpreter and want your AOLserver OO-Tcl Module
available in AOLServer workers, you need to provide a serialiser. Or,
you have the nifty feature of ttrace that comes with Naviserver. Either
way is a design problem of its own and non-trivial (especially in the OO
case). See the enlightening discussing over at naviserver-devel:
http://www.mail-archive.com/naviserv...@lists.sourceforge.net/msg00136.html
Gustaf Neumann
>
> One starting point I'd be willing to help on here is an openid client
> (since I've already started work on it).
>
Hi Jeff,
A few weeks ago i have made as well a small openid client
(using OpenACS, but not integrated with OpenACS authorities, cookies, etc).
git clone git://alice.wu-wien.ac.at/openid
Currently, this is just an openid 1.* implementation. Our goal is to provide
support for openID 2.0 in the near future and integrate it with the
OpenACS authorization system. Martin Matuska (working in my institute)
is now looking into these matters.
To use it, you need OpenACS 5.4 (maybe 5.3 is sufficient as well) and
a recent version of xotcl-core and tdom.
-gustaf neumann