Open letter to AgileWiki developers
Everyone,
I do hope you all can find something of interest below that you to contribute to. This list is just off the top of my head. I'd be more than glad to discuss other projects as well. For example, we need to be able to mirror the content of one system in others. Lots more coming, you can count on that.
Bill
Password Management --Bill
Problems with a p2p network of extensible nodes is that there is no central authority that can be trusted. You end up with too many passwords, as usual, for access control.
But you can trust your own client software, and if you use a public web service, you likely trust that as well. So why not have your point of entry into the network manage your passwords?
Likely also, you can group some of those hosts together and use a common password for them. Passwords then are assigned to individual hosts or to groups of hosts. And when you change passwords, that change should be communicated silently to all the hosts in the same group.
So we end up with something very much like single-signon, but where only the user needs to trust the point of entry. And we can use passwords to sign the messages as well.
I expect to have this complete (except for signing messages) in a day or two.
Web Front End --Naji
This is a huge project. Integration with Jetty, replacement of Browse with Comet. To date, a simple hello world has been released. I expect to participate in this project as well, but not any time soon. I expect that there will be pleanty of work here to keep any number of developers busy.
I already have an ISP where we can run this.
Access Control --Bill
With Web 3.0, you no longer need large capital expenditures to provide a service--the number of computers providing the service grows with the number of users. But think about it. If I'm keeping important information in my ark/repository/database, why would I let just anyone come and change it? And some of that information is confidential too!
For users to open their systems and really collaborate, we need access control. I've done this before and with relations already built in, it will not be hard.
Wiki --Bill
This is the beginning of semantics. As the repository is somewhat hierarchical, there are inherent problems in building a wiki on it--hierarchical wikis are always a good idea gone wrong. The fix is adding an applicative context, which gives you control over the namespace each page can use for referencing other pages.
I'd rather be writing docs than working on this project, so yes, I'd welcome the help here.
RSS Aggregator
The idea here is to feed the ark with content from multiple sources (information fusion), do a keyword search on the content and organize the incoming material on that basis. Norm (the father of Rolonics) has as an example over 200 feeds which he monitors. This would be a big help for him (our test user) and many others like him.
This project could be the first real application of AgileWiki--nothing else is needed. It is time to start this project now. First step, determine which rss aggregator(s) to integrate with.
Who wants to get started on this?
JXTA / JXTA 2 Integration
The current com package (nio sockets) might work in a business, but not out in the wilds of the internet. JXTA looks like the way to go. I see this as a necessary minimum to be a real Web 3.0 player.
I'd like to finish reworking the message formats (adding digital signatures) before this project gets too far along. But that shouldn't take too long.
Who wants to get started on this? I already have an ISP where we can run the core servers for this.
Developer Docs --Bill
By the end of March I hope to start working on this full time. But it would be very helpful if I could get a bunch of questions from everyone so I have some idea where to begin. I mean, the code all reads so clearly for me, but I suspect that is not the case for everyone else. To do a good job when writing, you need to understand the needs of the reader.
Everyone please, help me out on this. Thanks!
Email Client
I've worked in companies where everyone spent 6 hrs a day (no exageration!) reading and organizing their email, and a lot of those email were "things you might need to know" that were sent to everyone. Very few emails actually needed to be read immediately, but they all needed to be sorted out and organized. What a waste of time!
Integrating an email client into AgileWiki means that you can share not only the content, but the organizational structure. Again, this is all about information fusion and creating a useful organization of content. This could be a big time saver and an important application.
Having done this before, I'll note that the hard part is in presenting the email nicely. Seems like every email client structures the email slightly differently.
Any takers for this project?
Inferencing --Bill
Reasoning systems really aren't that hard to do. The tricky part is making them incrimental, so as the information changes, the inferences can be adjusted without having to start everything over again.
The relations already built into AgileWiki will be a starting point. And applicative context, which is part of the wiki implementation, is done, that will be the next part.
This will be a fun project, but we'll not be ready to start it for a while.
I do hope you all can find something of interest below that you to contribute to. This list is just off the top of my head. I'd be more than glad to discuss other projects as well. For example, we need to be able to mirror the content of one system in others. Lots more coming, you can count on that.
Bill
Password Management --Bill
Problems with a p2p network of extensible nodes is that there is no central authority that can be trusted. You end up with too many passwords, as usual, for access control.
But you can trust your own client software, and if you use a public web service, you likely trust that as well. So why not have your point of entry into the network manage your passwords?
Likely also, you can group some of those hosts together and use a common password for them. Passwords then are assigned to individual hosts or to groups of hosts. And when you change passwords, that change should be communicated silently to all the hosts in the same group.
So we end up with something very much like single-signon, but where only the user needs to trust the point of entry. And we can use passwords to sign the messages as well.
I expect to have this complete (except for signing messages) in a day or two.
Web Front End --Naji
This is a huge project. Integration with Jetty, replacement of Browse with Comet. To date, a simple hello world has been released. I expect to participate in this project as well, but not any time soon. I expect that there will be pleanty of work here to keep any number of developers busy.
I already have an ISP where we can run this.
Access Control --Bill
With Web 3.0, you no longer need large capital expenditures to provide a service--the number of computers providing the service grows with the number of users. But think about it. If I'm keeping important information in my ark/repository/database, why would I let just anyone come and change it? And some of that information is confidential too!
For users to open their systems and really collaborate, we need access control. I've done this before and with relations already built in, it will not be hard.
Wiki --Bill
This is the beginning of semantics. As the repository is somewhat hierarchical, there are inherent problems in building a wiki on it--hierarchical wikis are always a good idea gone wrong. The fix is adding an applicative context, which gives you control over the namespace each page can use for referencing other pages.
I'd rather be writing docs than working on this project, so yes, I'd welcome the help here.
RSS Aggregator
The idea here is to feed the ark with content from multiple sources (information fusion), do a keyword search on the content and organize the incoming material on that basis. Norm (the father of Rolonics) has as an example over 200 feeds which he monitors. This would be a big help for him (our test user) and many others like him.
This project could be the first real application of AgileWiki--nothing else is needed. It is time to start this project now. First step, determine which rss aggregator(s) to integrate with.
Who wants to get started on this?
JXTA / JXTA 2 Integration
The current com package (nio sockets) might work in a business, but not out in the wilds of the internet. JXTA looks like the way to go. I see this as a necessary minimum to be a real Web 3.0 player.
I'd like to finish reworking the message formats (adding digital signatures) before this project gets too far along. But that shouldn't take too long.
Who wants to get started on this? I already have an ISP where we can run the core servers for this.
Developer Docs --Bill
By the end of March I hope to start working on this full time. But it would be very helpful if I could get a bunch of questions from everyone so I have some idea where to begin. I mean, the code all reads so clearly for me, but I suspect that is not the case for everyone else. To do a good job when writing, you need to understand the needs of the reader.
Everyone please, help me out on this. Thanks!
Email Client
I've worked in companies where everyone spent 6 hrs a day (no exageration!) reading and organizing their email, and a lot of those email were "things you might need to know" that were sent to everyone. Very few emails actually needed to be read immediately, but they all needed to be sorted out and organized. What a waste of time!
Integrating an email client into AgileWiki means that you can share not only the content, but the organizational structure. Again, this is all about information fusion and creating a useful organization of content. This could be a big time saver and an important application.
Having done this before, I'll note that the hard part is in presenting the email nicely. Seems like every email client structures the email slightly differently.
Any takers for this project?
Inferencing --Bill
Reasoning systems really aren't that hard to do. The tricky part is making them incrimental, so as the information changes, the inferences can be adjusted without having to start everything over again.
The relations already built into AgileWiki will be a starting point. And applicative context, which is part of the wiki implementation, is done, that will be the next part.
This will be a fun project, but we'll not be ready to start it for a while.
Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here.
posted by Bill la Forge @ 11:02 AM
0 comments
0 Comments:
Post a Comment
<< Home