[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fsedu-developers] semanticWiki code so far
From: |
Stephen Compall |
Subject: |
Re: [Fsedu-developers] semanticWiki code so far |
Date: |
02 Nov 2003 23:27:33 +0000 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
James Michael DuPont <address@hidden> writes:
> I would like to be compatible with oddmuse. I will look into
> infinite monkey. A reuable perl class would be good. I think that
> an abstract model is in order here. From that we can generate code
> to implement the model.
The core is the wikilang->xhtml translation. Around that, we can wrap
the action system (presuming we're going to tear up oddmuse, of
course) as the driver, with the callbacks for I/O in the overrides. I
could randomly quote words in the last sentence for effect....
> > not really the content pages -- based on cookie data; this can be
> > done with a "custom directory" layout.
>
> You mean sessions.
Well, they are not really individualized -- except for the people with
permissions to edit the script. I am also thinking about restricting
modification of the tags, but this is probably just some paranoid
instinct cropping up.
About "edit the script": yes, I would like a PublicScript, or rather
something close to it (submit patches for instant approval &
application), even though it is not really required for the page
design I have in mind. It's just interesting.
> > The biggest addition is that of a central "tags" database: named
> > tags attached to documents, with or without values.
>
> Predicates in prolog, properties in rdf.
Why not keep it simple, and just say "<page> <something> true" in RDF?
> > I am painfully (again) learning perl (again).
>
> If you need any help...
Today I learned references, modules, and classes. I practiced by
creating a class, though I have not even gotten to inheritence in
perltoot yet. Yum.
> > Finally, I need to be able to cache the pieces: the header must be
> > regenerated every time the tags db changes,
>
> I hope that the changes will go through the business logic application
> server.
Sorry ... business logic?
> > portal pages also need to be regenerated every time the tags
> > change, but content pages only need to be regenerated every time
> > their content or their *own* tags change.
>
> ok. Dependancies.
The dependency specifics need to be defined by overrides, not in the
documents or tags themselves. The way I'm thinking, anyway.
> > All of this can be done by designing the backend and frontend classes
> > correctly (give enough override hooks, that is), yet keeping the
> > "normal" Infinite Monkey behavior the same, and preferably adding a
> > tags daemon.
>
> I dont think we need to make this in perl. We need to make it
> accessable via perl.
What do you mean by "this"? After all, the only motive I have for
perl at this point is so I don't have to write the whole thing from
scratch -- and keep the current storage format.
--
Stephen Compall or s11 or sirian
The only two things that motivate me and that matter to me are revenge
and guilt.
-- Elvis Costello
clandestine class struggle quiche Vickie Weaver fissionable Khaddafi
AIMSX 9705 Samford Road smuggle covert video PLO spy bullion Albright
FIPS140