P2P CMS/PM system with SeaSide and TeaTime

> 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 talked to the OpenCobalt developers and they were very positive about
> the feasibility of the idea and gave me a lot of good advice and links
> to check out including Seaside which seems like it could the ideal
> technology to build our system in.
>
> We have a specific application in mind that we'd 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 Seaside developers think of the idea of extracting the TeaTime
> P2P aspect of OpenCobalt and running Seaside on it so we could build P2P
> browser-based applications?
>
> We have a good budget available for this and will be developing it as a
> completely free open source system, so we'd also like to hear from
> developers who may be interested in working on the project too.

> Hi, I'm part of a development team who are helping an organisation to
> architect a free CMS based project-management system 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 talked to the OpenCobalt developers and they were very positive about
> the feasibility of the idea and gave me a lot of good advice and links
> to check out including Seaside which seems like it could the ideal
> technology to build our system in.
>
> We have a specific application in mind that we'd 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 Seaside developers think of the idea of extracting the TeaTime
> P2P aspect of OpenCobalt and running Seaside on it so we could build P2P
> browser-based applications?
>
> We have a good budget available for this and will be developing it as a
> completely free open source system, so we'd also like to hear from
> developers who may be interested in working on the project too.
>
> Thanks a lot,
> Aran
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> Hi Aran -
>
> I'm not sure who you talked to but there's really no meaningful
> definition of the term "P2P" that applies to Teatime as implemented in
> Hedgehog (which is what Cobalt is built upon). Teatime is a
> synchronization mechanism for distributed objects, but it can be built
> with or without using P2P communication. Early Teatime versions used P2P
> (rather: multi-cast) but the version implemented in Hedgehog (and
> Cobalt) does not use P2P communication, for various reasons.
>
> From what I've seen in the Cobalt discussions[1,2], I would agree with
> the person who mentioned the replication features of CouchDB or similar.
> It looks like this would be a better and more straightforward fit with
> what you've been describing in that discussion.
>
> [1]http://groups.google.com/group/opencobalt/browse_thread/thread/ae071311a099be9a
>
> [2]http://groups.google.com/group/opencobalt/browse_thread/thread/9829a8971570ba5c
>
>
> Cheers,
>   - Andreas
>
> On 1/10/2011 3:12 PM, Aran Dunkley wrote:
>> Hi, I'm part of a development team who are helping an organisation to
>> architect a free CMS based project-management system 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 talked to the OpenCobalt developers and they were very positive about
>> the feasibility of the idea and gave me a lot of good advice and links
>> to check out including Seaside which seems like it could the ideal
>> technology to build our system in.
>>
>> We have a specific application in mind that we'd 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 Seaside developers think of the idea of extracting the TeaTime
>> P2P aspect of OpenCobalt and running Seaside on it so we could build P2P
>> browser-based applications?
>>
>> We have a good budget available for this and will be developing it as a
>> completely free open source system, so we'd also like to hear from
>> developers who may be interested in working on the project too.
>>
>> Thanks a lot,
>> Aran
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>

> Sorry for the confusion, maybe P2P is too general a term, and I may have
> misunderstood the specifics of what components do what in the Cobalt
> system. Here's more information on what we're wanting to develop:
>
> The users will be running a p2p application which forms a DHT from all
> the currently online instances. The CMS/Project management application
> is used via the browser like a normal web-application, but the address
> of it resolves to localhost and uses the local p2p application is it's
> backend "web-server" and the DHT as the persistent storage layer with
> local caching as necessary etc.
>
>
> The users then go to the URL of the project management system
>
> On 11/01/11 19:24, Andreas Raab wrote:
>> Hi Aran -
>>
>> I'm not sure who you talked to but there's really no meaningful
>> definition of the term "P2P" that applies to Teatime as implemented in
>> Hedgehog (which is what Cobalt is built upon). Teatime is a
>> synchronization mechanism for distributed objects, but it can be built
>> with or without using P2P communication. Early Teatime versions used P2P
>> (rather: multi-cast) but the version implemented in Hedgehog (and
>> Cobalt) does not use P2P communication, for various reasons.
>>
>>  From what I've seen in the Cobalt discussions[1,2], I would agree with
>> the person who mentioned the replication features of CouchDB or similar.
>> It looks like this would be a better and more straightforward fit with
>> what you've been describing in that discussion.
>>
>> [1]http://groups.google.com/group/opencobalt/browse_thread/thread/ae071311a099be9a
>>
>> [2]http://groups.google.com/group/opencobalt/browse_thread/thread/9829a8971570ba5c
>>
>>
>> Cheers,
>>    - Andreas
>>
>> On 1/10/2011 3:12 PM, Aran Dunkley wrote:
>>> Hi, I'm part of a development team who are helping an organisation to
>>> architect a free CMS based project-management system 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 talked to the OpenCobalt developers and they were very positive about
>>> the feasibility of the idea and gave me a lot of good advice and links
>>> to check out including Seaside which seems like it could the ideal
>>> technology to build our system in.
>>>
>>> We have a specific application in mind that we'd 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 Seaside developers think of the idea of extracting the TeaTime
>>> P2P aspect of OpenCobalt and running Seaside on it so we could build P2P
>>> browser-based applications?
>>>
>>> We have a good budget available for this and will be developing it as a
>>> completely free open source system, so we'd also like to hear from
>>> developers who may be interested in working on the project too.
>>>
>>> Thanks a lot,
>>> Aran
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> Sorry for the confusion, maybe P2P is too general a term, and I may have
> misunderstood the specifics of what components do what in the Cobalt
> system. Here's more information on what we're wanting to develop:
>
> The users will be running a p2p application which forms a DHT from all
> the currently online instances. The CMS/Project management application
> is used via the browser like a normal web-application, but the address
> of it resolves to localhost and uses the local p2p application is it's
> backend "web-server" and the DHT as the persistent storage layer with
> local caching as necessary etc.

> So basically you're saying that content is going to be stored in a DHT?
> That sounds reasonable if you're trying to avoid any particular
> centralized "server" instance but, honestly, I would a) not take that
> approach unless I had a Very Good Reason (tm) for doing so (what exactly
> is wrong with server to begin with? and how is that not addressed by
> adding fail-over and replication capabilities?) and b) Croquet/Cobalt
> will not be helping you with your DHT work.
>
> Unfortunately, the Croquet site is down right now (we're working on
> getting it back up) otherwise I'd add a link to our Hedgehog
> presentation which might clarify what Croquet is and what it isn't.
>
> Cheers,
>   - Andreas
>
> On 1/10/2011 10:37 PM, Aran Dunkley wrote:
>> Sorry for the confusion, maybe P2P is too general a term, and I may have
>> misunderstood the specifics of what components do what in the Cobalt
>> system. Here's more information on what we're wanting to develop:
>>
>> The users will be running a p2p application which forms a DHT from all
>> the currently online instances. The CMS/Project management application
>> is used via the browser like a normal web-application, but the address
>> of it resolves to localhost and uses the local p2p application is it's
>> backend "web-server" and the DHT as the persistent storage layer with
>> local caching as necessary etc.
>>
>>
>> The users then go to the URL of the project management system
>>
>> On 11/01/11 19:24, Andreas Raab wrote:
>>> Hi Aran -
>>>
>>> I'm not sure who you talked to but there's really no meaningful
>>> definition of the term "P2P" that applies to Teatime as implemented in
>>> Hedgehog (which is what Cobalt is built upon). Teatime is a
>>> synchronization mechanism for distributed objects, but it can be built
>>> with or without using P2P communication. Early Teatime versions used P2P
>>> (rather: multi-cast) but the version implemented in Hedgehog (and
>>> Cobalt) does not use P2P communication, for various reasons.
>>>
>>>  From what I've seen in the Cobalt discussions[1,2], I would agree with
>>> the person who mentioned the replication features of CouchDB or similar.
>>> It looks like this would be a better and more straightforward fit with
>>> what you've been describing in that discussion.
>>>
>>> [1]http://groups.google.com/group/opencobalt/browse_thread/thread/ae071311a099be9a
>>>
>>>
>>> [2]http://groups.google.com/group/opencobalt/browse_thread/thread/9829a8971570ba5c
>>>
>>>
>>>
>>> Cheers,
>>>    - Andreas
>>>
>>> On 1/10/2011 3:12 PM, Aran Dunkley wrote:
>>>> Hi, I'm part of a development team who are helping an organisation to
>>>> architect a free CMS based project-management system 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 talked to the OpenCobalt developers and they were very positive about
>>>> the feasibility of the idea and gave me a lot of good advice and links
>>>> to check out including Seaside which seems like it could the ideal
>>>> technology to build our system in.
>>>>
>>>> We have a specific application in mind that we'd 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 Seaside developers think of the idea of extracting the
>>>> TeaTime
>>>> P2P aspect of OpenCobalt and running Seaside on it so we could build
>>>> P2P
>>>> browser-based applications?
>>>>
>>>> We have a good budget available for this and will be developing it as a
>>>> completely free open source system, so we'd also like to hear from
>>>> developers who may be interested in working on the project too.
>>>>
>>>> Thanks a lot,
>>>> Aran
>>>> _______________________________________________
>>>> seaside-dev mailing list
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>
>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>