agilewiki-wiki — General discussion.

[AgileWiki] Fixing the tables at agilewiki.org

[Bill La F. <Wil...@Su...>]

Until we have the post command, I will only fix /DescriptorUnits at 
agilewiki.org. However, it is easy to fix the descriptor units in you 
home drawer. Just login, go to home, destroy your home cabinet, and then 
re-register.

I've already used this approach to fix /User-AdMin/DescriptorUnits and 
/User-BillLaForge/DescriptorUnits.

Of course, if you're not using tables then this is not a pressing issue. :-)

Bill

[AgileWiki] 1.0.1.0 --what does it all mean

[Bill La F. <Wil...@Su...>]

The big thing is that table commands can be thiner, and some we do not need.

For example, we need a command for ordering LSecs. But now that command 
can also be used for ordering the rows in a table. Further, removing a 
row can now be done by destroying an LSec.

And now that a row is a rolon, editing a row means navigating to the 
LSec and then operating on that LSec. Also, as I had previously 
mentioned, each row now has its own journal.

I'll note that this folding of table rows onto LSecs could not be done 
in AW2 for speed considerations. But AW3 is fast enough that this is no 
longer a consideration. Indeed, you could say that putting tables in 
documents was a hold over from AW2 that has only now been corrected.

Bill

[AgileWiki] alpha release 3.0.1.0, intentions

[Bill la F. <bil...@su...>]

This morning I released 3.0.1.0, which I'm calling alpha. It is also 
installed at agilewiki.org. As there is no conversion program, I've got 
to go in and manually repair any existing tables on agilewiki.org. 
fortunately we now have enough capability to be able to do that.

So, we no longer store tables in documents. Note however that in 
TableRolon, it is docEvent which is still used to display the table. 
That's our convention--docEvent is used for custom displays.

Now a few changes in intention. I figure 3.1.0.0 will now be the beta 
release. I want to get it out in a week, so most things tagged for 3.1 
will be retagged to 3.2.

One thing I especially want to do this week is to get simpleAccounting 
working. At the moment, most of the code is simply commented out.

Bill

[AgileWiki] table displays are working

[Bill la F. <bil...@su...>]

I've now readded the display for tables. Looks good.

I've also done a little testing with the agilewiki.org log files. Looks 
quite salvagable.

Bill

[AgileWiki] Tables are now redone

[Bill la F. <bil...@su...>]

OK, now the tables are redone. The LSecs of a Table are its rows. And 
the old code is GONE!

Hmm. I have a worry--all that content on agilewiki.org. So I need to 
test with the log files I've downloaded. Lets see what happens.

Bill

[AgileWiki] strategy

[Bill la F. <bil...@su...>]

I am upset about falling back to alpha, but I'll get over it.  :'(

Meanwhile, its not as bad as many of the changes that I made while AW2 
was in beta. Of course, that was a prototype.

The main thing is that we use tables for are:

1. SimpleAccounting - this has been dropped from the rolons.txt and 
commands.txt files.

2. Defining tables (columns table).

3. The Users table, which is the basis for access control.

This is pretty small. Most of the recoding will be done in the DuDrawer 
rolon.

Bill

[AgileWiki] Scrap tables?

[Bill la F. <bil...@su...>]

I am quite unhappy with multi-column tables stored in document content.

1. It is not too effficient from a storage perspective, as a change to a 
part of a document adds another copy of the whole document to the 
database--we don't do diffing.

2. It seems like an enormous duplication. Consider an alternative table 
rolon whose lsecs are the rows. Column values can then be stored as LEnts.

I've been working on the simple accounting application. I'll note that 
with each row implemented as an LSec, you now have a journal for each 
account. Much better. And remember that, like rows, LSecs can be ordered.

I just wish we had done this before declaring beta.

Food for thought. Any comments?

Bill

[AgileWiki] Release 3.0.0.1 has been installed and is running on agilewiki.org

[Bill la F. <bil...@su...>]

Note that in addition to the bug fix, the new SimpleAccounting commands 
are in place--still missing the accountEntry command.

Hit it again, Damian! :-)

Bill

[AgileWiki] Fixed: oops did I break it?

[Bill la F. <bil...@su...>]

Silly error. Fixed and checked in. Looks to me like we need a release soon.

Bill

Bill la Forge wrote:

> Looks like a bug to me. :-)
>
> Thanks Damien! Every one counts.
>
> (Its back up. Enjoy!)
>
> Bill
>
> Exception during request procesing: java.lang.ClassCastException 
> org.agilewiki.ark.rolons.JSecRolon
> java.lang.ClassCastException: org.agilewiki.ark.rolons.JSecRolon
>        at 
> org.agilewiki.framework.apps.createlsec.CreateLSecCmd.applicable(CreateLSecCmd.java:56) 
>
>        at org.agilewiki.ark.rolons.Rolon.getCmd(Rolon.java:72)
>        at org.agilewiki.ark.rolons.Rolon.getCmds(Rolon.java:95)
>        at org.agilewiki.ark.rolons.Rolon.getCmds(Rolon.java:125)
>        at org.agilewiki.ark.rolons.JSecRolon.getCmds(JSecRolon.java:67)
>        at org.agilewiki.framework.Session.getCmds(Session.java:398)
>        at org.agilewiki.framework.Session.process(Session.java:527)
>        at 
> org.agilewiki.framework.Portal.processClientRequest(Portal.java:117)
>        at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>        at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
>
>        at java.lang.reflect.Method.invoke(Method.java:585)
>        at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>        at sun.rmi.transport.Transport$1.run(Transport.java:153)
>        at java.security.AccessController.doPrivileged(Native Method)
>        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>        at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
>        at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) 
>
>        at java.lang.Thread.run(Thread.java:595)
>
>
> ------------------------------------------------------------------------
>
> Subject:
> oops did I break it?
> From:
> Damien Cooke <Dam...@Su...>
> Date:
> Sat, 08 Jul 2006 20:41:49 +0930
> To:
> Bill la Forge <bil...@su...>
>
>
> It liiks like AWServer is down?
>
>  
>

[AgileWiki] Fwd: oops did I break it?

[Bill la F. <bil...@su...>]

Looks like a bug to me. :-)

Thanks Damien! Every one counts.

(Its back up. Enjoy!)

Bill

Exception during request procesing: java.lang.ClassCastException 
org.agilewiki.ark.rolons.JSecRolon
java.lang.ClassCastException: org.agilewiki.ark.rolons.JSecRolon
        at 
org.agilewiki.framework.apps.createlsec.CreateLSecCmd.applicable(CreateLSecCmd.java:56)
        at org.agilewiki.ark.rolons.Rolon.getCmd(Rolon.java:72)
        at org.agilewiki.ark.rolons.Rolon.getCmds(Rolon.java:95)
        at org.agilewiki.ark.rolons.Rolon.getCmds(Rolon.java:125)
        at org.agilewiki.ark.rolons.JSecRolon.getCmds(JSecRolon.java:67)
        at org.agilewiki.framework.Session.getCmds(Session.java:398)
        at org.agilewiki.framework.Session.process(Session.java:527)
        at 
org.agilewiki.framework.Portal.processClientRequest(Portal.java:117)
        at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at 
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
        at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
        at java.lang.Thread.run(Thread.java:595)

[AgileWiki] table contents cache working, simple ledger rewritten

[Bill la F. <bil...@su...>]

Sougata and all,

With the old API, the SimpleLedger code was quite verbose. But by fixing 
the table content cache, making it a smart wirte cache, and by having a 
custom display that handles the running totals rather than having the 
running totals in the table itself, things have shrunk nicely.

I will need to document this stuff. One change is the new deploy command 
which creates the descriptor unit. Ah! We no longer need to create a new 
database for each new application! :-) (But note that you need to be in 
the DescriptorUnit for the deploy command to be applicable.)

Another aspect is that the crSimpleAccounting command now requires the 
SimpleAccountingDescriptorUnit to be present for it to be applicable. So 
the application does not run in cabinets where you have not deployed its 
descriptor units.

Still need to add the accountEntry command. Then it will be rude, crude, 
but still a usable accounting system. :-)

Now I'm thinking that once the documentation is done for the application 
platform, we can declare that we have achieved 3.1. That will make it a 
bad wiki that is also a reasonable application platform. A bit odd, what?

Bill

[AgileWiki] smart table write cache

[Bill la F. <bil...@su...>]

When you get the content of a table within the context of a transaction, 
it now marks the table content as dirty.

Later, when the transaction commits, it checks the contents of the 
table. If the contents have indeed changed, then
it updates the document content of the table rolon.

Sounds like it should work. Later today I'll work on the new Simple 
Accounting application--that will give it a good workout.

Bill

[AgileWiki] agilewiki.org is back up again

[Bill la F. <bil...@su...>]

Hopefully the ISP is over the worst of the relocation now. I just 
restarted AwServer and things look ok.

Bill

[AgileWiki] Please welcome Pawan Kumar Shrivastava

[Bill la F. <bil...@su...>]

I am happy to introduce Pawan Kumar Shrivastava to this list:

I am interested to work in this project. I am
working as a technical architect in UK, and having 7+
years of experience in Java, J2EE, Swing , EJB etc.

Bill

[AgileWiki] An AW assignment for my day job

[Bill La F. <Wil...@Su...>]

I've been asked to put up an AW server at work for a particular project. 
Some requirements also need to be met--these will be added as features 
to AW. I'm quite delighted.

One way I can meet some of the particular requirements is to display the 
document content of one rolon within the display of another. This 
results in a composit document where various parts can have comments 
attached. So I'm thinking of a simple extension to brace notation to 
achieve this.

Bill

[AgileWiki] A Sun blog

[Bill La F. <Wil...@Su...>]

I've just started another blog at 
http://blogs.sun.com/roller/page/laforge49/ for both work related items 
and the occasional anouncement about AgileWiki.

Meanwhile, I'll continue with the blog at http://laforge49.blogspot.com/ 
as an informal project log with the occasional personal note.

Enjoy!

Bill

[AgileWiki] rolonic structures

[Bill la F. <bil...@su...>]

I wrote the following in answer to a query from a developer. I thought 
it might be helpful.

Bill

Rolonics is a theory of knowledge based in part on holonics. We break 
the world into rolons rather than objects. And every rolon has four 
aspects: wholness, partness, state and history.

You could say that rather than have just data and metadata, we subdivide 
data int ledger (state) and journal (changes/history), and subdivide 
metadata into descriptors (behavior/wholeness) and classifiers 
(relationships/partness).

The structures then are very simple. Each rolon can have a document 
(multi-line ascii text), and entries (name/value pairs). There are three 
kinds of entries: classifier, descriptor and ledger. There is also a 
rich set of relationships supported. Right now we've only got a few to 
start with:

A rolon can have children (rolons).
A rolon can have parents (rolons).
A rolon can have ledger sections (rolons).
A rolon can have a descriptor unit (rolon) which defines its type and 
defines common behavior.
A rolon can have journal sections (rolons) which describe every change 
that has been made to that rolon.

And of course, everything is recursive in multiple dimensions. So a 
rolon can have a descriptor unit which has a ledger section which has a 
journal section which has a descriptor unit. It looks simple at first 
glance, and it really is simple. But it is a very rich system.

These are only the basic structures. We've built a wiki on this, and the 
next step is to build up an application platform.

Additionally, a rolon can have classifier sections (rolons) of about 5 
different types for defining more interesting relationships. These were 
implemented in the prototype (AgileWiki2) in Python, but AgileWiki3 
(intended to be a fast production system) isn't there yet.

[AgileWiki] Applications--install, deploy, create

[Bill la F. <bil...@su...>]

I want to start my recalling the initial work that Sougata did on 
applications. Really very helpful. Up to that point, I had not thought 
very deeply about applications--always there was something else of 
higher priority to think about. Now all that is changed and applications 
are the highest priority. And I've given a lot of thought to the issues 
that Sougata uncovered.

First things first--the package. All the code for an application should 
be in a single package. Makes it easy to add and easy to purge. And the 
only hooks are in the rolons.txt, commands.txt and fields.txt files. So 
eventually we may want some property file which describes an application 
and a utility which updates these files accordingly. That would be cool, 
but not pressing. (And a nice standalone java program, if anyone is 
interested.)

Now once the administrator has installed the bits, updated the .txt 
files and rebooted the server, we're ready to deploy. I figure every 
application would have a deploy command which is scoped for the 
DuDrawerRolon and is applicable to anyone with update access. A user 
then visits the DescriptorUnits Drawer and runs the deploy command. This 
is when the application's descriptor unit(s) is created.

Then we have the application's create command(s). These commands would 
only be applicable when the appropriate descriptor unit has been 
installed in the current Cabinet's DescriptorUnits Drawer.

Additional commands for the application are scoped to the application's 
own rolons. Further, these rolons can override the docEvent method, for 
custom displays when appropriate.

What do you think?

Bill

[AgileWiki] docEvent

[Bill La F. <Wil...@Su...>]

I've been thinking about how to implement custom displays for 
applications, poked a bit at the code and suddenly realized that there 
is already a mechanism in place!

  public void docEvent(EventComposer composer, ViewSessionInterface 
session, Timestamp t)
    throws Exception

This method exists on Rolon, but is overridden by TableRolon. So an 
application just needs to override this method and, ipso facto, you have 
a custom display.

:-)

Bill

[AgileWiki] It is all so clear to me now

[Bill la F. <bil...@su...>]

AgileWiki3.0 implements a (basic) set of Rolonic structures.

Rolonics is like the unified theory of application development, where 
ANY application can be viewed from a Rolonic perspective and 
consequently mapped into Rolonic structures.

So AgileWiki3.0 implements much of the structure needed by ANY application.

What we need most in AgileWiki3.1 then is to implement an Application 
Programmer's Interface (API), and at least one application.

Bill

Re: [AgileWiki] Please welcome Damien Cooke to the AgileWiki developersgroup

[Norm K. <nr...@cm...>]

Welcome Damien,

I'm afraid my dear friend Bill is trying to corrupt you into a new way of
thinking.  :-)

Thank you for joining us.  ;-norm

-----Original Message-----
From: com...@li...
[mailto:com...@li...] On Behalf Of Bill La
Forge
Sent: Wednesday, July 05, 2006 6:31 AM
To: com...@li...
Subject: [AgileWiki] Please welcome Damien Cooke to the AgileWiki
developersgroup

I'm very happy to introduce a co-worker, Damien Cooke.

Damien is from down under, works in Market Development Engineering (as 
do I) at Sun Microsystems. He came to Bangalore for a year-end staff 
meeting and, well, I did a little arm twisting. So now he's on the list.

My hope is that Damien can take the lead on developing some tools that 
we can use internally at Sun. The catch, of course, is that we need to 
make some progress towards 3.1 before we can start building real 
applications. Guess that gives him some time to read over the 
documentation. :-)

Bill

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Compstrm-wiki mailing list
Com...@li...
https://lists.sourceforge.net/lists/listinfo/compstrm-wiki

[AgileWiki] ready to release, removeParent

[Bill la F. <bil...@su...>]

I wrote the removeParent command this AM, and that was the final piece.

We are ready now for our first beta release, 3.0.0.0.

Cheers!

Bill

[AgileWiki] Please welcome Damien Cooke to the AgileWiki developers group

[Bill La F. <Wil...@Su...>]

I'm very happy to introduce a co-worker, Damien Cooke.

Damien is from down under, works in Market Development Engineering (as 
do I) at Sun Microsystems. He came to Bangalore for a year-end staff 
meeting and, well, I did a little arm twisting. So now he's on the list.

My hope is that Damien can take the lead on developing some tools that 
we can use internally at Sun. The catch, of course, is that we need to 
make some progress towards 3.1 before we can start building real 
applications. Guess that gives him some time to read over the 
documentation. :-)

Bill

[AgileWiki] Open Issues for AW3.1

[Bill La F. <Wil...@Su...>]

The beta release will be version 3.0, and is planned for this weekend. I 
considered calling it 3.1, but overall AW is simply too weak to be 
anything but a .0 release. :-(

Meanwhile, I've identified the items to be worked on for AW3.1. The 
emphasis will be on making AW more usable as a Wiki as well as adding 
support for AW as an application server. These items have been noted in 
the OpenIssues Cabinet at agilewiki.org.

In selecting the work items for 3.1, I wanted to keep a reasonably tight 
focus, while adding significantly to the overall utility of AW both from 
a user and a developer perspective. My hope is that AW3.1 will be a tool 
worth learning.

Any thoughts you may have would be appreciated. Feel free to sign up to 
work on anything that may interest you!

Bill

[AgileWiki] server went down today, outage tomorrow

[Bill la F. <bil...@su...>]

Our ISP lost internet access for 25 minutes today and when service 
restored, AwServer was down. There was no traceback.

There is also a planned outage tomorrow--our ISP is relocating the servers.

Bill