agilewiki-wiki — General discussion.

[AgileWiki] lists and classifier sections

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

There are lots of times when you want to define a list, especially as we 
move more to applications. It seems proper that a list is defined by a 
rolon. The list would be a subset of the rolon's namespace, including 
only the child Topics, LSecs, references and the part of the namespace 
defined by the classifier sections. However the rolon itself would be 
excluded, as well as siblings, ancestors and any namespace inherited 
from the rolon's parent(s). Another way of saying this is that the list 
includes the intentional part of the namespace but excludes the 
contextual part of the namespace.

Now you can  reference  a rolon in a LEnt and use it as a list of 
accounts, a list of clients, etc. But we can now also define list 
classifiers for adding a carefully crafted set of rolons to the 
namespace of another rolon.

Hmm. Sounds like something else that needs to be cached.

Bill

[AgileWiki] 3.2 is out

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

3.2 has been installed on agilewiki.org and released.

Time for a break!

Bill

[AgileWiki] the short list

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

Here are some things that need to be fixed before 3.2 is released:

1. addParent is overly restrictive now

2. various displays now need to list usage--very helpful when using 
move, demote and promote

3. headline display should support wiki names and brace notation.

So we're talking about releasing 3.2 in a day or so. I just like to see 
some cleanup before a major release.

Bill

[AgileWiki] The Classifier/Ledger dualism

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

Norm,

I know Rolonics is a quadism of wholeness/descriptors, 
partness/classifiers, structure/ledger and stream/journal, with the 
major dualisms being wholeness-partness and structure-stream.

With my earlier work on Quick, I am a past master of the 
structure-stream dualism, or at least major aspects of it.

I also remember having long talks with you about access control. The 
user name is a classifier, but Restrict and Private are descriptor 
entries. So access control is an aspect of the wholeness-partness domain.

But what I've only just come to understand is the partness-structure 
dualism. And I've been working with it for 6 years now! It is how you 
build knowledge structures. The classifiers are used to define the 
namespace and the ledgers reference names, though in the wiki the 
references are always in the document. But now we are supporting Ledger 
Entries of type pathname, and that will be more than handy for building 
application-specific structures.

So what else am I missing? This is only 3 of the 6 dualisms. 
Wholeness-structure seems realitively obvious. Wholeness-stream and 
partness-stream are a bit less obvious, but seem to apply to some of the 
streaming utilities. But I'd really like to hear more about these.

Bill

[AgileWiki] demote

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

Suprised myself--the demote command is done, tested and checked in.

Does this mean we are ready to do the 3.2 release? Almost. While testing 
I noticed the addParent command is a bit to restrictive. So I want to 
fix that.

Move, promote and demote went pretty quickly. But then the API is in 
better shape than it was in AW2, and I had already implemented them 
before (in AW2). Anyway, it was nice being able to zip them out.

Bill

[AgileWiki] the new promote command is working and checked in

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

Some nice progress today. The new promote command changes an LSec into a 
Page, a Page into a Folder and a Folder into a Drawer.

The command itself is not very difficult. The trick is in determining 
when it is applicable. For example, if the Rolon is specialized (say, it 
is a table or something), then it should not be promoted. Or if it is a 
folder with more than one parent. Or if it is a Page in a Folder (i.e. 
no headroom). The list seems endless.

Now all re need for release 3.2 is demote. But that's not for today, 
methinks.

Bill

[AgileWiki] post 3.1.4

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

Well, the release went out this morning, and 3.1.4 has been installed on 
agilewiki.org.

Note that you should delete the /DescriptorUnits drawer to allow a 
refresh after the install.

I have since enhanced the move command. It now checks for duplicates at 
the destination and supports renaming.

Meanwhile the promote and demote commands are on my short list prior to 
doing the 3.2 release. These commands, combined with move, lend some 
minimal agility to the AgileWiki. Of course, a post command (copy 
current state) would help a great deal.

Bill

[AgileWiki] some minor agility--move command

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

The move command looks like it is working. This command can move 
Folders, Pages and LSecs within a Cabinet.

Now, once we have promote and demote, we will have at least a minimum of 
agility.

Bill

Re: [AgileWiki] Norm, some thoughts on inherited namespace vs classifiers

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

Finally got a chance to have a long talk with Norm, including this 
topic. Conclusion: Topics are organized so you can find them, while 
Ledger Sections are used to create structures. And so the (unextended) 
namespace of a Topic is only its direct ancestors, siblings and 
children, while an LSec also inherits the namespaces of its parent.

This is a big divergence from AW2 and gives you a lot more control over 
topic namespaces... once classifiers are implemented.

Bill

Bill La Forge wrote:

> Norm, I really like analogies when reasoning about classifiers.
>
> Now in Java programming, namespace is inherited two different ways, 
> depending on granularity:
>
>    1. At the module level, only classifiers (include statements) and
>       full path names are used.
>    2. Within a module, a nested block inherits (structurally) from the
>       blocks it is embeded in.
>
> Now lets look at books. Again, I find the use of classifiers depends 
> on granularity:
>
>    1. A book takes no context from where it is located. Reshelving a
>       book in a library has little impact on its content.
>    2. Within a book, a chapter takes its general context from the
>       book, a section has the context of the chapter, etc.
>
> So I'm thinking we can apply the same approach to the Ark:
>
>    1. Topics (Ark, Cabinets, Drawers, Folders and Pages) should mostly
>       use explict classifiers for defining their namespace.
>       Reorganizing topics should not be difficult. Whereas
>       dependencies on where a topic is located would greatly reduce
>       the agility of the whole system.
>    2. Ledger Sections, while able to take advantage of classifiers to
>       extend their namespace, largely depend on the structure they are
>       in for their context and namespace.
>
> As I've always said, people tend to overlook the impact of 
> granularity. Things work different at different levels of 
> granularity--with fine granularity weak forces tend to dominate, while 
> strong forces dominate the larger levels of granularity. (If I may 
> borrow so blithly from physics!)
>
> Bill

[AgileWiki] a bit more flexibility

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

You can now create a Folder in the Ark or a Cabinet.

You can now create a Page in the Ark, a Cabinet or a Drawer.

This opens things up a bit to allow for greater agility.

Bill

[AgileWiki] Big change, new LSecRolon

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

I came close to breaking forward compatibility on this one, but 
LedgerSections are now LEntRolons, not NamedRolons. Just a bit of 
cleanup, but I changed the rolons.txt file so that old LSecs would have 
the proper class.

Should make the code a smaller bit more readable.

Bill

[AgileWiki] LedgerEntries table

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

DescriptorUnitDescriptorUnit and TableDescriptorUnitDescriptorUnit now 
both have a LedgerEntries table, though other descriptor units can also 
have such a table as needed. This table describes the LEnts of a Rolon 
much as the Columns table describes the LEnts in the rows of a table.

[AgileWiki] delegating access by groups

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

The missing piece of access control, for both AW2 and AW3 has been the 
ability for any but AdMin to add users to groups.

I've just finished the addUser command, which is scoped to Cabinets. It 
requires only that you be the administrator of that cabinet. And what it 
does is create a row under the /Users LSec.

This means that users, after doing a "home", can do an "addUser" to add 
users to groups named in their own cabinet. Oh, and the addUser command 
also displays the rows relating to the current cabinet--it tries to be nice.

Unfortunately, I still need a way to remove a user. I expect this will 
be done by navigating to the offending row under /Users (which can be 
done via the addUser command) and then doing a remove. To this end, the 
rows under /Users are UsersRowRolons, not RowRolons. This way the remove 
command can be scoped to the rows of the Users lsec.

All this is a bit awkward, because only AdMin has write access to /Users 
and its rows. And that's vital, because this is a big part of the 
AgileWiki's security system.

Bill

[AgileWiki] language

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

It is good to see this mailing list working again. Sourceforge is no 
longer reporting a problem at http://sourceforge.net/docs/A04/

Last time I talked with Norm, he was expressing a strong desire for a 
command language, and I just brushed it off saying we use XML. But I'll 
note that the XML requests to the server are not what you want to enter 
manually. We also have a batch facility left over from the start of AW3, 
but its been a long time now since I looked at it.

Lately I've been thinking about how application code all but disapears. 
Well, with a better command language there is much less of a need for an 
API except for those things that can't be expressed in that language. It 
would be easy to, for example, take SimpleAccounting's deploy command 
and convert it into a command to create a descriptor unit, mm? Then the 
install just needs to add the batch script.

This is definately an aspect to be worked on. We could reorganize the 
XML being passed to the server a bit to make the command portion 
distinct, and perhaps make the batch input compatible with that--current 
syntax for batch is just not rich enough.

Bill

[AgileWiki] it is too simple

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

http://blogs.sun.com/roller/page/laforge49?entry=it_is_too_simple

If you're having troble with understanding Rolonics or its value, catch 
the above blog.

Bill

[AgileWiki] test

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

Re: [AgileWiki] Compstrm-wiki Digest, Vol 3, Issue 26 ...1) Some UML from Gordon(Bill la Forge)

[gordan m. <gor...@ya...>]

 
  Using Netbeans 5.5 IDE I was with reverse engineering generated class diagram
  of agilewiki3 alpha 3.1.2.0 project. This class diagram consist all class and methods and
  parameters as one of Unified Modeling Language modeling.
   
  Other class diagram I was generated from agilewiki3 alpha7 (old version) which 
  represent simplification  of actual version of agilewiki and help to better 
  understend principls of agilewiki3 functionality.
  
 
  
1. Some UML from Gordon (Bill la Forge)



I received two UML diagrams from Gordon, which I've posted to the 
project site at:
https://agilewiki.dev.java.net/servlets/ProjectDocumentList?folderID=0

Bill



 		
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.

[AgileWiki] A more natural PIM

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

http://blogs.sun.com/roller/page/laforge49?entry=a_more_natural_pim

The above is the latest in my attemt to justify some of the strong 
claims I make about Rolonics.

[AgileWiki] evidence of increasing interest in AgileWiki3

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

http://sourceforge.net/project/stats/detail.php?group_id=106672&ugn=compstrm&type=prdownload&mode=year&year=2006&package_id=179488

The above URL plots the number of downloads of AgileWiki3 per month. It 
is not very impresive yet, but it does trend nicely upwards. :-)

Bill

[AgileWiki] new mantra: applications, applications, applications

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

Full steam ahead is not always best. Take time to document, yes, I've 
done some of that. But as we approach 3.2, my thoughts are also turning 
to applications. How can we claim AgileWiki is an application platform 
for the next generation of software without a collection of sample 
applications?

One that I've thought of that can work using only the facilities to be 
released in 3.2 is a check register. It works like SimpleAccounting, 
except that there is only one account--so we don't need a table with 
rows. Rather we just need a current balance and 3 subclasses of JSec: 
deposit, check and ATM withdrawal. For each of these there would also be 
a command to do same. And then there would be queries for a date range. 
(Or perhaps for the last N transactions.) And custom displays, of 
course, for each of the subclasses of JSec.

I thought of two more, actually. But these require classifiers. We'll 
get there.

Bill

[AgileWiki] reorderingn priorities (again)

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

I'm thinking that the priorites for agility vs classifiers is just 
wrong. First because a lot of the agility logic will need to be changed 
when we add classifiers. And second, because content depends on 
classifiers and agility has no value without content.

So leading up to 3.3, we should be working on classifiers, and only 
after that should we be addressing agility. This is a change that has 
slowly been creeping up on me, first when I decided to focus on 
validatation to the exclusion of agility for the 3.2 release, and 
subsequently as my thoughts have more and more been turning to 
classifiers rather than agility.

I'll note that I've been very happy with the tight focus on validation. 
AW3 now has capabilities (relating to tables and rows) which Norm and I 
had discussed in the context of AW2, but never implemented. And I am 
very much looking forward to working on the remaining items for the 3.2 
release--especially, finally, the allow and disallow commands on the 
Users table which will complete access control.

Bill

[AgileWiki] Norm, some thoughts on inherited namespace vs classifiers

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

Norm, I really like analogies when reasoning about classifiers.

Now in Java programming, namespace is inherited two different ways, 
depending on granularity:

   1. At the module level, only classifiers (include statements) and
      full path names are used.
   2. Within a module, a nested block inherits (structurally) from the
      blocks it is embeded in.

Now lets look at books. Again, I find the use of classifiers depends on 
granularity:

   1. A book takes no context from where it is located. Reshelving a
      book in a library has little impact on its content.
   2. Within a book, a chapter takes its general context from the book,
      a section has the context of the chapter, etc.

So I'm thinking we can apply the same approach to the Ark:

   1. Topics (Ark, Cabinets, Drawers, Folders and Pages) should mostly
      use explict classifiers for defining their namespace. Reorganizing
      topics should not be difficult. Whereas dependencies on where a
      topic is located would greatly reduce the agility of the whole system.
   2. Ledger Sections, while able to take advantage of classifiers to
      extend their namespace, largely depend on the structure they are
      in for their context and namespace.

As I've always said, people tend to overlook the impact of granularity. 
Things work different at different levels of granularity--with fine 
granularity weak forces tend to dominate, while strong forces dominate 
the larger levels of granularity. (If I may borrow so blithly from physics!)

Bill

And have you ever calculated the gravitational forces attracting two 
neutrons in an area the size of an atomic nucleus? Perhaps dark matter 
simply lacks electrons and protons? :-)

[AgileWiki] Some UML from Gordon

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

I received two UML diagrams from Gordon, which I've posted to the 
project site at:
https://agilewiki.dev.java.net/servlets/ProjectDocumentList?folderID=0

Bill

[AgileWiki] 3.1.3.0 installed and released

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

https://sourceforge.net/forum/message.php?msg_id=3834544

Catch the above release notice for details about the release.

Note also that after installing 3.1.3.0, I deleted the DescriptorUnits 
Drawer in all the Cabinets, allowing the system to rebuild them afresh. 
(A new feature of this release.)

Enjoy!

Bill

[AgileWiki] Simple accounting display reworked

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

I've now reworked the simple accounting display. The account number is 
now clickable.

Definately ready for a release now.

Bill