Re: [Open Cobalt Group] Using OpenCobalt as a P2P browser-basedapplication framework
as...@askoh.com
Thanks for your interest. What you suggest seems very interesting and
appropriate to Open Cobalt and the entire Squeak community. Open Cobalt
can provide the P2P and virtual world framework. Seaside or Aida has
the dynamic web framework. Pier is a CMS system. Magma is an object
database. And there is more. I believe the Squeak community has the
expertises and the necessary software components to help you.
How can we discuss more of the specifics that you wish to have or accomplish?
All the best,
Aik-Siong Koh
On Wed, 05 Jan 2011 12:42:22 1300, Aran Dunkley wrote:
Hi, I'm part of a development team who are helping an organisation to
> architect a CMS based project that they want to work in a P2P network
> rather than using a centralised web-server.
>
> We've researched existing CMS's such as Plone to see if they could be
> modified to operate on top of a DHT but found that they rely too heavily
> on querying methodologies that are incompatible with the P2P paradigm.
>
> I realise that Cobalt is really intended as a virtual world system, but
> it seems that it has a lot of the P2P applicational functionality in
> place that could be developed to serve content to a local standard browser.
>
> We have a specific application in mind that we like to develop which is
> a project-management/workflow environment running in a CMS with some
> other standard tools such as wiki/blog, but rather than a web-server
> we'd be using a local P2P app as the backend. I'm wondering what you
> guys, the OpenCobalt developers, think of the practicalities of this idea?
>
> We have a good budget available for this and will be developing it as a
> completely free open source component, so we'd also like to hear from
> developers who may be interested in working on the project too.
>
> Thanks a lot,
> Aran
>
> --
> You received this message because you are subscribed to the "Open
Cobalt" Google group.
> To post to this group, send email to openc...@googlegroups.com
> To unsubscribe from this group, send email to
> opencobalt unsub...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opencobalt?hl=en
>
>
Aran Dunkley
Here's some more detail of our project:
What we're developing is best described as a web site since it will run
in a normal browser and appear to be a normal kind of wiki/blog site.
It doesn't need to handle enormous traffic on any one article like
wikipedia would because it's more group-centric to help small
organisations to collaborate on content, make decisions together and do
basic project management. In fact we'd probably be enforcing some kind
of splitting of large traffic nodes into smaller ones, for example
dividing large organisations into smaller departments to ensure that
each portal of activity always has a practical number of active members.
One of the parts of this system is an interface allowing organisation's
members to collaborate on their own applicational requirements by
supplying an interface for creating and maintaining collections of
workflows and forms and conditions for them to move between roles.
The reason we won't be extending an existing system like Drupal or Plone
is that we have a strict requirement to do this in a serverless way, and
it looks like this requirement needs to be designed for right from the
ground up since real-time queries on a global data-set would choke the
network.
To deal with this we're ensuring that the architecture avoids
network-wide queries/searches. Any such queries, for example a list of
the 5 newest organisations in the network, would be handled as a
directory (in the p2p space) that's updated when an organisation is
created, rather than a query being broadcast around the network when a
peer needs the list.
With this general "directory not search" approach to the architecture
we'd be minimising the expectations we have for the p2p networks
performance.
We also intend that the system be used by many organisations that have
very low quality or limited connectivity, so we'd be designing in
long-term eventual consistency and edit-conflict workflow mechanisms.
I'm working on the architecture and have some idea about how to achieve
this, but we're looking for a lead developer with good P2P experience to
guide us in the core technology decisions. For example maybe we don't
need all the capabilities of TeaTime and a simple DHT might suffice, or
maybe a standard CMS can be modified more easily than we think.
We still have a lot of research to do, and all your comments and advice
are very much appreciated :-)
Thanks a lot,
Aran
Patrick
Sounds like CouchDB's replication feature could provide all the P2P
horse power your project needs. See the section on "Distributed
Updates and Replication" here: http://couchdb.apache.org/docs/overview.html.
Adding Seaside for web UI and Pier CMS and/or Gjallar collaboration to
a CouchDB back-end could be a comprehensive solution. To get an idea
of what's possible with workflows, forms and roles, check out
Gjallar's features here: http://www.gjallar.se/gjallar/7.
Thanks,
Patrick