Plone

›

General Questions

Looking for collaborators

16 Messages

Mike Pelletier

Reply Threaded

Greetings, Plone community.

CaseWare International is working on a number of Plone products and
enhancements. They are all intended to be released under the GPL. We
presently have four full-time developers on our "OpenEngagement"
project, and several more working on Plone projects for clients. We
are interested in coordinating development with other developers to
reduce wasted effort. I would like to take the list on a brief tour
of our open and future projects. If you have a libre project similar
to one of ours and would like to reach your goals sooner, or if you
can get value from one of our projects and want to see it released
sooner, please get in touch with myself or brett.kennedy@....

Our projects, from most to least complete:

RoleMap -- Our application makes heavy use of local roles to designate
responsibility for various procedures. For example, it does not make
sense in our case to have a site-wide list of Reviewers, since
documents are assigned for review on an individual basis, and it
should not be possible for a user to approve a document if they have
not been specifically assigned that duty. To make it more practical
to get an overview of pending tasks, we have created a product that
presents a view much like the standard Site Map, but personalised to
the user and organised by the roles they have been assigned to each
item. We intend to release this as a stand-alone product, and would
also be interested in having it rolled into Plone if there is
sufficient interest.

NoProblem -- We have developed a product to: allow end users to submit
problem reports in response to server exceptions (overrides error
page) or at will; allow administrators to view the Zope event log
through a Plone-friendly interface; and provide an API for plugging in
"consistency checks" of the contents of the ZODB, keyed by class or
interface. Presently problem reports are merely sent to a
configurable email address. It would be nice to be able to support
issue trackers, or to keep a database of problem reports on the server
(though this would need to be augmented with other methods, for
example if the problem is exhausted disk space).

ExternalStorage and related technologies -- Our CMS requirements
typically involve large files that change relatively frequently. We
don't want to store these "blobs" in the ZODB. We have had a number
of problems with ExternalStorage relating to staying synchronised with
ZODB transactions. The release version of ExternalStorage does not
deal with issues like undo, versioning, and most especially with
database conflicts. After a conflict, the ZODB gets rolled back, but
the external file does not, which can result in data loss. We have
developed some quick hacks to prevent loss, but they come with some
caveats of their own. We wish to develop a robust and general
solution.

ContentHistory, CMFEditions, etc -- This is a good example of where we
have failed to coordinate with the community in the past. Our market
requires a "paper trail" of all operations performed on CMS data. We
started out simply listening for object creation, modification and
deletion events, and recording them. During development of
ContentHistory, the scope was expanded to also allow state snapshots,
which could be used to revert to prior states (without destroying any
history). It has not been reworked to cover these requirements, as
CMFEditions seemed to have matured somewhat by then. When we started,
CMFEditions was languishing and did not appear to be appropriate for
our needs, but since then it has received new development. We would
like to help with future development and throw our use cases into the
pot to hopefully help further generalise the product.

The following projects are all still in the concept stage.

Document signing -- The content in our application is typically edited
outside of Plone through a check in/check out mechanism. Content
review also generally occurs outside Plone's demesne. As an
unfortunate consequence, there can be many copies and versions of a
document in existence outside of the CMS. Furthermore, due to the
nature of the documents, our typical user is very concerned with the
possibility of documents being tampered with. To safeguard against
accidental or intentional document corruption and confusion, we are
considering a digital signature system. We are interested in
discussing this with other developers who have similar problems, and
working together for a solution.

Outlook integration -- Due to changing business practices in the US
and elsewhere, it is becoming critical to capture even the most
ephemeral communications and knowledge. We would like to use Plone to
record and index all corporate email. We don't presently see a need
for a full web-mail interface, the intent is merely to archive email
that might have legal significance, and expire it promptly when
legally permitted to do so. Since we would still want to protect
confidentiality within the organisation, this probably butts up
against a number of other issues -- eg, how best to unify the user
database with the mail server, how to describe which pools of users
can read each other's mail, etc. The stated intent is to integrate
with Outlook/Exchange, but I expect a more general solution that
includes the Microsoft world would be even better. The project
manager adds, "There are legal issues related to storing emails. We'll
have to research them further. I assume they vary from country to
country. This won't stop us, just complicate our lives."

Google Desktop integration -- Sort of a free-association idea at this
point, not well defined or researched. Both directions of integration
could be useful; enter a query into Google Desktop and receive results
from the portal, or enter queries into the portal and receive results
from a pool of Google Desktop instances scattered around a network.
We're interested in hearing about any work along these lines.

Project management tools -- Another loosely-defined idea. Presently,
we make much use of CMS work-flow. This tends to deal with questions
regarding what needs to be done now. We would like to extend this
into the past and future, to help set goals, analyse whether they are
being met, help schedule complex, composite tasks, and make
predictions about completion dates. This would either be a fully
Plone-based solution, or integration with existing project management
tools.

Find and replace -- We understand that this is a desired but
unimplemented core feature. We would like to implement it, and to
first hear from prior attempts, expected gotchas, etc.

Support for hand-held devices -- We also understand that there have
been some attempts to make this a core feature. We think it would be
very useful to our audience, and are interested in developing this
feature. Any guidance and review of historic attempts would be very
welcome.

Thanks for reading through to this point. We are looking forward to
greater collaboration in the future, and to contributing to the Plone
community.

Mike.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

Martin Aspeli-2

Re: Looking for collaborators

Reply Threaded

Hi Michel

Good to hear from you again :)

> RoleMap -- Our application makes heavy use of local roles to designate
> responsibility for various procedures. For example, it does not make
> sense in our case to have a site-wide list of Reviewers, since
> documents are assigned for review on an individual basis, and it
> should not be possible for a user to approve a document if they have
> not been specifically assigned that duty. To make it more practical
> to get an overview of pending tasks, we have created a product that
> presents a view much like the standard Site Map, but personalised to
> the user and organised by the roles they have been assigned to each
> item. We intend to release this as a stand-alone product, and would
> also be interested in having it rolled into Plone if there is
> sufficient interest.

I'm not quit sure I understand it. Is there an example anywhere?

> NoProblem -- We have developed a product to: allow end users to submit
> problem reports in response to server exceptions (overrides error
> page) or at will; allow administrators to view the Zope event log
> through a Plone-friendly interface; and provide an API for plugging in
> "consistency checks" of the contents of the ZODB, keyed by class or
> interface. Presently problem reports are merely sent to a
> configurable email address. It would be nice to be able to support
> issue trackers, or to keep a database of problem reports on the server
> (though this would need to be augmented with other methods, for
> example if the problem is exhausted disk space).

Isn't this a bit like PloneErrorReporting? Being able to plug in custom
checks is interesting, though.

> ExternalStorage and related technologies -- Our CMS requirements
> typically involve large files that change relatively frequently. We
> don't want to store these "blobs" in the ZODB. We have had a number
> of problems with ExternalStorage relating to staying synchronised with
> ZODB transactions. The release version of ExternalStorage does not
> deal with issues like undo, versioning, and most especially with
> database conflicts. After a conflict, the ZODB gets rolled back, but
> the external file does not, which can result in data loss. We have
> developed some quick hacks to prevent loss, but they come with some
> caveats of their own. We wish to develop a robust and general
> solution.

ExternalStorage is quite simple, indeed. I know FileSystemStorage has a
few more features, but I haven't used it (it felt rather too large for
our needs the last time around, like ... it has a configlet for setting
options globally).

Better large file/document handling is very much in scope for Plone 3.5,
so if you have resources to commit to this, it's probably a very good
time to start!

Note that long term a lot of people are hoping the ZODB Blob Support by
Christian Theune and Chris McDonough will land us the BLOB support. I'm
not sure about the technical detail of this myself, though!

> ContentHistory, CMFEditions, etc -- This is a good example of where we
> have failed to coordinate with the community in the past. Our market
> requires a "paper trail" of all operations performed on CMS data. We
> started out simply listening for object creation, modification and
> deletion events, and recording them. During development of
> ContentHistory, the scope was expanded to also allow state snapshots,
> which could be used to revert to prior states (without destroying any
> history). It has not been reworked to cover these requirements, as
> CMFEditions seemed to have matured somewhat by then. When we started,
> CMFEditions was languishing and did not appear to be appropriate for
> our needs, but since then it has received new development. We would
> like to help with future development and throw our use cases into the
> pot to hopefully help further generalise the product.

CMFEditions will be part of Plone 3.0. If you can help test it and make
it as robust as possible, this will likely be a very good use of your
time, since you'll benefit from it being part of the core.

> The following projects are all still in the concept stage.
>
> Document signing -- The content in our application is typically edited
> outside of Plone through a check in/check out mechanism. Content
> review also generally occurs outside Plone's demesne. As an
> unfortunate consequence, there can be many copies and versions of a
> document in existence outside of the CMS. Furthermore, due to the
> nature of the documents, our typical user is very concerned with the
> possibility of documents being tampered with. To safeguard against
> accidental or intentional document corruption and confusion, we are
> considering a digital signature system. We are interested in
> discussing this with other developers who have similar problems, and
> working together for a solution.

Plone 3.0 will (almost certainly) ship with 'iterate' by Kapil as a
staging solution. This builds on CMFEditions and is apparently quite
simple (though I've not had a chance to look at it myself yet). I'd
recommend you try to plug into this if possible.

Iterate also needs a bit of last-five-percent work before it's merged,
so now is a good time to pick up on this.

> Outlook integration -- Due to changing business practices in the US
> and elsewhere, it is becoming critical to capture even the most
> ephemeral communications and knowledge. We would like to use Plone to
> record and index all corporate email. We don't presently see a need
> for a full web-mail interface, the intent is merely to archive email
> that might have legal significance, and expire it promptly when
> legally permitted to do so. Since we would still want to protect
> confidentiality within the organisation, this probably butts up
> against a number of other issues -- eg, how best to unify the user
> database with the mail server, how to describe which pools of users
> can read each other's mail, etc. The stated intent is to integrate
> with Outlook/Exchange, but I expect a more general solution that
> includes the Microsoft world would be even better. The project
> manager adds, "There are legal issues related to storing emails. We'll
> have to research them further. I assume they vary from country to
> country. This won't stop us, just complicate our lives."

Good luck ;)

'listen' is generally known as the best email solution in Plone, but
this is about mailing lists, not storing email.

Also, bear in mind that most organisations send a *lot* of emails, often
with big attachments. The ZODB implications may be non-trivial.

> Google Desktop integration -- Sort of a free-association idea at this
> point, not well defined or researched. Both directions of integration
> could be useful; enter a query into Google Desktop and receive results
> from the portal, or enter queries into the portal and receive results
> from a pool of Google Desktop instances scattered around a network.
> We're interested in hearing about any work along these lines.

Certainly, writing an indexer for Google Desktop that would search an
arbitrary Plone site would be really, really cool! This direction of
integration sounds more useful to me. I have no idea how extensible
Google Desktop is, though.

> Project management tools -- Another loosely-defined idea. Presently,
> we make much use of CMS work-flow. This tends to deal with questions
> regarding what needs to be done now. We would like to extend this
> into the past and future, to help set goals, analyse whether they are
> being met, help schedule complex, composite tasks, and make
> predictions about completion dates. This would either be a fully
> Plone-based solution, or integration with existing project management
> tools.

This is a complex problem. Issue trackers like Poi may get you some of
the way. There's also ZEPP, PloneTimeTracker and others. But people tend
to have very specific needs for project management.

> Find and replace -- We understand that this is a desired but
> unimplemented core feature. We would like to implement it, and to
> first hear from prior attempts, expected gotchas, etc.

Performance? I'm not aware of any non-bespoke-script-like solution to this.

> Support for hand-held devices -- We also understand that there have
> been some attempts to make this a core feature. We think it would be
> very useful to our audience, and are interested in developing this
> feature. Any guidance and review of historic attempts would be very
> welcome.

There is mobile.css which renders Plone for mobiles. I don't know how
mature it is or what other features you need, though.

Martin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

Brett Kennedy

Re: Looking for collaborators

Reply Threaded

Hi, I also work at CaseWare with Mike and can maybe answer a couple
questions.

1. The Role Map
This product is pretty much ready now for us to put up somewhere for
others to download & use. Where the sitemap might look something like:

Folder 1
Folder 1A
File A
File B
Folder 1B
File C
File D
Folder 2
Folder 2A
File E
File F
Folder 2B
File G
File H

The role map would look like this:

Folder 1 (Alice: Manager, Preparer)
Folder 1A
File A
File B
Folder 1B
File C (Bob: Reviewer; Carol: Reader, Reviewer)
File D
Folder 2
Folder 2A
File E
File F
Folder 2B (David: Manager)
File G
File H

So, it looks like the site map but also shows the local & inherited
roles. The inherited roles are shown by colouring the tree below any
given local role.

We've added combo boxes where users can specify to show only certain
users and/or certain roles to avoid too much clutter as well.

3. External Storage
We've really not enhanced the functionality of External Storage - just
fixed this one bug. It was a serious bug though, we feel. I'm not sure
if FSS has the same bug or not.

4. Content History/CMF Editions
Good to hear CMF Editions will be included. Content History, is, I
think, a very useful, general feature. It records all activity on the
site (object creation, user roles assignments, deletes, renames etc.),
by whom and when, thereby providing a complete audit trail. We had
intended at one point to have this code also implement versioning, but
will hold off until CMF Editions is ready instead and use that. We're
happy to test & debug CMF Editions in the mean time though. Our Content
History tool is ready.

5. Outlook
Yes we will need good luck. Another team here (c++ desktop application)
has already done this with their product so we hope to be able to take
advantage of that.

6. Google Desktop
We haven't done much design on this, but definitely wish to work on
this.

7. Project Management Tools
Our primary market is accounting firms, so it's possible our solution
will be specific to that. We hope to make it generic though. It may be
necessary since every firm has their own system. We would like to add
PERT & GANTT charts, and possibly some more administrative pages,
similar to the RoleMap, except tracking progress.

8. Find & Replace
I know a lot of people have asked about this and there is no solution
yet for a reason. We would like to add this though and have some design
ideas.

9. Hand-held devices
Do you know where we can try the .css file you mention? We're thinking
of developing different page templates to be used for hand-held devices
that just give the sort of summary information likely to be requested by
people using hand-held devices (ex busy executives in taxis). We could
try to work towards a css-based solution though.

Brett

-----Original Message-----
From: plone-users-bounces@...
[mailto:plone-users-bounces@...] On Behalf Of Martin
Aspeli
Sent: December 7, 2006 5:55 PM
To: plone-users@...
Subject: Re: [Plone-Users] Looking for collaborators

Hi Michel

Good to hear from you again :)

I'm not quit sure I understand it. Is there an example anywhere?

Isn't this a bit like PloneErrorReporting? Being able to plug in custom
checks is interesting, though.

ExternalStorage is quite simple, indeed. I know FileSystemStorage has a
few more features, but I haven't used it (it felt rather too large for
our needs the last time around, like ... it has a configlet for setting
options globally).

Better large file/document handling is very much in scope for Plone 3.5,

so if you have resources to commit to this, it's probably a very good
time to start!

Note that long term a lot of people are hoping the ZODB Blob Support by
Christian Theune and Chris McDonough will land us the BLOB support. I'm
not sure about the technical detail of this myself, though!

Good luck ;)

'listen' is generally known as the best email solution in Plone, but
this is about mailing lists, not storing email.

Also, bear in mind that most organisations send a *lot* of emails, often

with big attachments. The ZODB implications may be non-trivial.

> Google Desktop integration -- Sort of a free-association idea at this
> point, not well defined or researched. Both directions of integration
> could be useful; enter a query into Google Desktop and receive results
> from the portal, or enter queries into the portal and receive results
> from a pool of Google Desktop instances scattered around a network.
> We're interested in hearing about any work along these lines.

Certainly, writing an indexer for Google Desktop that would search an
arbitrary Plone site would be really, really cool! This direction of
integration sounds more useful to me. I have no idea how extensible
Google Desktop is, though.

> Project management tools -- Another loosely-defined idea. Presently,
> we make much use of CMS work-flow. This tends to deal with questions
> regarding what needs to be done now. We would like to extend this
> into the past and future, to help set goals, analyse whether they are
> being met, help schedule complex, composite tasks, and make
> predictions about completion dates. This would either be a fully
> Plone-based solution, or integration with existing project management
> tools.

This is a complex problem. Issue trackers like Poi may get you some of
the way. There's also ZEPP, PloneTimeTracker and others. But people tend

to have very specific needs for project management.

> Find and replace -- We understand that this is a desired but
> unimplemented core feature. We would like to implement it, and to
> first hear from prior attempts, expected gotchas, etc.

Performance? I'm not aware of any non-bespoke-script-like solution to
this.

> Support for hand-held devices -- We also understand that there have
> been some attempts to make this a core feature. We think it would be
> very useful to our audience, and are interested in developing this
> feature. Any guidance and review of historic attempts would be very
> welcome.

There is mobile.css which renders Plone for mobiles. I don't know how
mature it is or what other features you need, though.

Martin

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

Martin Aspeli-2

Re: Looking for collaborators

Reply Threaded

Brett Kennedy wrote:

> 1. The Role Map
> This product is pretty much ready now for us to put up somewhere for
> others to download & use. Where the sitemap might look something like:
>
> Folder 1
> Folder 1A
> File A
> File B
> Folder 1B
> File C
> File D
> Folder 2
> Folder 2A
> File E
> File F
> Folder 2B
> File G
> File H
>
> The role map would look like this:
>
> Folder 1 (Alice: Manager, Preparer)
> Folder 1A
> File A
> File B
> Folder 1B
> File C (Bob: Reviewer; Carol: Reader, Reviewer)
> File D
> Folder 2
> Folder 2A
> File E
> File F
> Folder 2B (David: Manager)
> File G
> File H
>
> So, it looks like the site map but also shows the local & inherited
> roles. The inherited roles are shown by colouring the tree below any
> given local role.
>
> We've added combo boxes where users can specify to show only certain
> users and/or certain roles to avoid too much clutter as well.

Interesting. It sounds like it'd be most useful as a third party product
to start with. If it catches on, I'm sure merging it for 3.5 or
something would be simple.

> 3. External Storage
> We've really not enhanced the functionality of External Storage - just
> fixed this one bug. It was a serious bug though, we feel. I'm not sure
> if FSS has the same bug or not.

Did you commit the fix to svn?

> 4. Content History/CMF Editions
> Good to hear CMF Editions will be included. Content History, is, I
> think, a very useful, general feature. It records all activity on the
> site (object creation, user roles assignments, deletes, renames etc.),
> by whom and when, thereby providing a complete audit trail. We had
> intended at one point to have this code also implement versioning, but
> will hold off until CMF Editions is ready instead and use that. We're
> happy to test & debug CMF Editions in the mean time though. Our Content
> History tool is ready.

Right, that's great. I think having two separate packages makes sense.
Are you using Zope 3 events to listen for object created, modified etc?
In Plone 3.0, at least, the sending of events will be better and more
predictable.

> 5. Outlook
> Yes we will need good luck. Another team here (c++ desktop application)
> has already done this with their product so we hope to be able to take
> advantage of that.
>
>
> 6. Google Desktop
> We haven't done much design on this, but definitely wish to work on
> this.

I'm sure this would be popular if released!

> 7. Project Management Tools
> Our primary market is accounting firms, so it's possible our solution
> will be specific to that. We hope to make it generic though. It may be
> necessary since every firm has their own system. We would like to add
> PERT & GANTT charts, and possibly some more administrative pages,
> similar to the RoleMap, except tracking progress.

Sounds interesting.

> 8. Find & Replace
> I know a lot of people have asked about this and there is no solution
> yet for a reason. We would like to add this though and have some design
> ideas.

Cool.

> 9. Hand-held devices
> Do you know where we can try the .css file you mention? We're thinking
> of developing different page templates to be used for hand-held devices
> that just give the sort of summary information likely to be requested by
> people using hand-held devices (ex busy executives in taxis). We could
> try to work towards a css-based solution though.

Point your Trio at a Plone site? Limi knows more, though.

Martin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

justizin-2

Re: Looking for collaborators

Reply Threaded

On 12/7/06, Mike Pelletier <mike@...> wrote:
> Greetings, Plone community.

Howdy! :)

> CaseWare International is working on a number of Plone products and
> enhancements. They are all intended to be released under the GPL. We
> presently have four full-time developers on our "OpenEngagement"
> project, and several more working on Plone projects for clients. We
> are interested in coordinating development with other developers to
> reduce wasted effort. I would like to take the list on a brief tour
> of our open and future projects. If you have a libre project similar
> to one of ours and would like to reach your goals sooner, or if you
> can get value from one of our projects and want to see it released
> sooner, please get in touch with myself or brett.kennedy@....
>
> Our projects, from most to least complete:
>
> RoleMap -- Our application makes heavy use of local roles to designate
> responsibility for various procedures. For example, it does not make
> sense in our case to have a site-wide list of Reviewers, since
> documents are assigned for review on an individual basis, and it
> should not be possible for a user to approve a document if they have
> not been specifically assigned that duty. To make it more practical
> to get an overview of pending tasks, we have created a product that
> presents a view much like the standard Site Map, but personalised to
> the user and organised by the roles they have been assigned to each
> item. We intend to release this as a stand-alone product, and would
> also be interested in having it rolled into Plone if there is
> sufficient interest.

This is a neat idea.. It could jive with the needs for SIGGRAPH
electronic conference submissions, but I don't think Plone is in the
running for that work until 2011.

I am also working on a custom issue tracking solution which would be
built to replace the default contact-info form, which mails webmaster.
I'd love to collaborate and to make this generally available.

I'm working off of the Poi issue tracker as a base, but I actually
want something slightly lighter for some cases. For reporting bugs in
a website, Poi might be just fine. I often use the releases
'production' and 'development' to track bugs in projects that are not
versioned, so much as deployed.

Okay:

(a) ExternalStorage is old, but still good-ish.
(b) FileSystemStorage, FWIW, has the same problems, but worse
(c) blobstorage supercedes ES for the most part, is destined for
Plone3, and addresses some, but not all, of your concerns.

I'd love to see continued work on having external file storage work
with versioning, transactions, etc.. It has occurred to me more than
once that files could be stored along with a timestamp / version
number in their filename. The transaction machinery could handle a
hard link where it is supported.

I like the sound of this a lot.. I've long wanted better logging of
activity - not for all deployments, but for some.

I would love to work with you guys on this.

This sounds neat.. I'm moving away from e-mail for many purposes and
toward issue trackers, which helps with this a great deal, but I can
see how you'd want to sniff.

> Google Desktop integration -- Sort of a free-association idea at this
> point, not well defined or researched. Both directions of integration
> could be useful; enter a query into Google Desktop and receive results
> from the portal, or enter queries into the portal and receive results
> from a pool of Google Desktop instances scattered around a network.
> We're interested in hearing about any work along these lines.

I wonder if Enfold Desktop handles anything along these lines and/or
could be integrated with Google.

> Project management tools -- Another loosely-defined idea. Presently,
> we make much use of CMS work-flow. This tends to deal with questions
> regarding what needs to be done now. We would like to extend this
> into the past and future, to help set goals, analyse whether they are
> being met, help schedule complex, composite tasks, and make
> predictions about completion dates. This would either be a fully
> Plone-based solution, or integration with existing project management
> tools.

I'm working on something along these lines, based loosely on issue
tracking, and also on Martin Fowler's Planning pattern.

> Find and replace -- We understand that this is a desired but
> unimplemented core feature. We would like to implement it, and to
> first hear from prior attempts, expected gotchas, etc.
>
> Support for hand-held devices -- We also understand that there have
> been some attempts to make this a core feature. We think it would be
> very useful to our audience, and are interested in developing this
> feature. Any guidance and review of historic attempts would be very
> welcome.

I believe technically that this IS a supported core feature, but most
of us wouldn't know how effective it is.

I know that I have had clients open their site with their cell phone,
without my doing anything, and report that they are very pleased.

> Thanks for reading through to this point. We are looking forward to
> greater collaboration in the future, and to contributing to the Plone
> community.

w00t! Drinks all around on Mike's tab! ;)

--
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

justizin-2

Re: Looking for collaborators

Reply Threaded

On 12/8/06, Justizin <justizin@...> wrote:
> On 12/7/06, Mike Pelletier <mike@...> wrote:
> > Greetings, Plone community.
>
> Howdy! :)
>

>
> > ExternalStorage and related technologies -- Our CMS requirements
> > typically involve large files that change relatively frequently. We
> > don't want to store these "blobs" in the ZODB. We have had a number
> > of problems with ExternalStorage relating to staying synchronised with
> > ZODB transactions. The release version of ExternalStorage does not
> > deal with issues like undo, versioning, and most especially with
> > database conflicts. After a conflict, the ZODB gets rolled back, but
> > the external file does not, which can result in data loss. We have
> > developed some quick hacks to prevent loss, but they come with some
> > caveats of their own. We wish to develop a robust and general
> > solution.
>
> Okay:
>
> (a) ExternalStorage is old, but still good-ish.
> (b) FileSystemStorage, FWIW, has the same problems, but worse
> (c) blobstorage supercedes ES for the most part, is destined for
> Plone3, and addresses some, but not all, of your concerns.
>
> I'd love to see continued work on having external file storage work
> with versioning, transactions, etc.. It has occurred to me more than
> once that files could be stored along with a timestamp / version
> number in their filename. The transaction machinery could handle a
> hard link where it is supported.
>

BTW, the one thing I don't like about blobstorage is that it uses
uids. This makes sense, but is very inconvenient. There is a lovely
systems branch of ES which should work with many sites in one
instance.

I'd love to see this fleshed out a bit. Some filesystems, e.g. Reiser
and possible XFS, allow for 'streams', which might be ideal for
storage of versioned, ACID-y external resources.

--
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

Mike Pelletier

Re: Looking for collaborators

Reply Threaded

On Thursday 07 December 2006 17:54, Martin Aspeli wrote:
> Hi Michel
>
> Good to hear from you again :)

I'll take that, but I should mention that this isn't Michel, it's "the other
Mike"; http://www.zope.org/Members/MikeP . If it wasn't for Michel
Pelletier, I swear I wouldn't get half the work I do. Oh, shoot, my employer
is reading this.

It is also good to hear from you.

I'll try to address anything Brett missed yesterday.

> > NoProblem -- We have developed a product to: ...

> Isn't this a bit like PloneErrorReporting? Being able to plug in custom
> checks is interesting, though.

Quite a lot like, yes. Another difference (I think; I can't presently load
the PER page) is that NoProblem records the traceback and exception in the
user's session, and includes it with the completed problem report. Also, it
has a cool, soothing icon.

It sounds like we should get in touch with Hanno Schlichting and merge any
actual improvements into his. We can easily split the ZODB consistency
checking features into a new Product.

> > ExternalStorage and related technologies --

In another message, Martin asks if we have submitted our fixes. No. They are
pretty stop-gap. We solved the problem by making all filesystem writes
non-destructive. That way, when the ZODB component of a filesystem resource
gets rolled back, the file that it previously pointed to is still available.
The fix is not complete, however. There are rare cases that can cause
overwrites since we are using simple counters to create filenames (for
example, go into a version, re-upload an existing file, exit a version and
then re-upload to the same file). There is also the problem that data hangs
around for ever and needs to be expired by some external process.

All in all, still not a desirable situation, but better than the data loss we
were frequently seeing previously. Perhaps combined with CMFEditions, a
better solution can be found.

> Better large file/document handling is very much in scope for Plone 3.5,
> so if you have resources to commit to this, it's probably a very good
> time to start!
>
> Note that long term a lot of people are hoping the ZODB Blob Support by
> Christian Theune and Chris McDonough will land us the BLOB support. I'm
> not sure about the technical detail of this myself, though!

I'll leave commitments of resources to Brett, but I'd bet we will want to get
involved in at least one of these projects. We started on an inhouse
solution for stashing blobs in arbitrary external stores, but it didn't get
beyond requirements and a pretty rough set of interfaces. (Hi, Chris
McDonough! It's been far too long since we whinged at each other. Also, hi,
Kibo! I don't know you.)

> CMFEditions will be part of Plone 3.0. If you can help test it and make
> it as robust as possible, this will likely be a very good use of your
> time, since you'll benefit from it being part of the core.

It's certainly not an easy problem, and I'd be thrilled for it to be not-mine.
I will see if I can't integrate the standalone Product into our application
next week. We are presently targetting Plone 2.5, it'll likely be some while
yet before we move to 3.0.

> > Document signing -- The content in our application is typically edited

> Plone 3.0 will (almost certainly) ship with 'iterate' by Kapil as a
> staging solution. This builds on CMFEditions and is apparently quite
> simple (though I've not had a chance to look at it myself yet). I'd
> recommend you try to plug into this if possible.
>
> Iterate also needs a bit of last-five-percent work before it's merged,
> so now is a good time to pick up on this.

I'm not certain this is actually what we are after. The sort of document
signing we're after is PKI-based. Most of it will happen outside of Plone.
What we'd like to add to Plone is the ability to verify signatures, possibly
to manage public keys, and maybe even give Plone itself the ability to
digitally sign documents in the rare case that it mutates them. I think you
were confused by my poor description into thinking we wanted to enhance the
review facilities provided by Plone, but really we want to use PKI to allow
some of the workflow to happen outside of Plone, to better fit our customer's
existing methodologies. Plone would peel off and validate successive signed
envelopes to figure out what has happened to a document since it was last
checked in.

Or something. This is all very tentative and based on a couple of bullet
points from a meeting I didn't attend. ;-)

> Right, that's great. I think having two separate packages [ContentHistory,
> CMFEditions] makes sense.

I sort of presumed that as long as you were tracking historical states of a
document, it would be a good place to start to also provide reporting on the
history of a document. But not having looked at CMFEditions yet, I could be
way off base. I do not mind keeping ContentHistory separate.

> Are you using Zope 3 events to listen for object created, modified etc?
> In Plone 3.0, at least, the sending of events will be better and more
> predictable.

Yes, and that is good to hear, but we have to support at least late versions
of Zope 2. I have noticed a few cases where I have not received the events I
was expecting, and I'm afraid I'm going to have to make history logging
voluntary in these cases. Obviously much rather not. Its not such a big
deal for us since we only support the content types we have written so we can
make the required calls to ContentHistory, but it sure makes it a much less
generally useful Product.

Thanks for your valuable time and attention, Martin. I understand we've
already got a couple responses off-list, so things are going well already,
and we're looking forward to becoming more involved in the future.

Mike.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

Martin Aspeli-2

Re: Looking for collaborators

Reply Threaded

Hi Mike,

> I'll take that, but I should mention that this isn't Michel, it's "the other
> Mike"; http://www.zope.org/Members/MikeP . If it wasn't for Michel
> Pelletier, I swear I wouldn't get half the work I do. Oh, shoot, my employer
> is reading this.

That's the most confusing thing ever :)

>>> NoProblem -- We have developed a product to: ...
>
>> Isn't this a bit like PloneErrorReporting? Being able to plug in custom
>> checks is interesting, though.
>
> Quite a lot like, yes. Another difference (I think; I can't presently load
> the PER page) is that NoProblem records the traceback and exception in the
> user's session, and includes it with the completed problem report. Also, it
> has a cool, soothing icon.

Hehe, great. Perhaps it could be folded into PER?

> It sounds like we should get in touch with Hanno Schlichting and merge any
> actual improvements into his. We can easily split the ZODB consistency
> checking features into a new Product.

+1

I think consistency checking is a really cool thing to have, and also
that it should be in a separate product.

>>> ExternalStorage and related technologies --
>
> In another message, Martin asks if we have submitted our fixes. No. They are
> pretty stop-gap. We solved the problem by making all filesystem writes
> non-destructive. That way, when the ZODB component of a filesystem resource
> gets rolled back, the file that it previously pointed to is still available.
> The fix is not complete, however. There are rare cases that can cause
> overwrites since we are using simple counters to create filenames (for
> example, go into a version, re-upload an existing file, exit a version and
> then re-upload to the same file). There is also the problem that data hangs
> around for ever and needs to be expired by some external process.
>
> All in all, still not a desirable situation, but better than the data loss we
> were frequently seeing previously. Perhaps combined with CMFEditions, a
> better solution can be found.

I have some hope for blobstorage in the ZODB + CMFEditions, yes.

>> Better large file/document handling is very much in scope for Plone 3.5,
>> so if you have resources to commit to this, it's probably a very good
>> time to start!
>>
>> Note that long term a lot of people are hoping the ZODB Blob Support by
>> Christian Theune and Chris McDonough will land us the BLOB support. I'm
>> not sure about the technical detail of this myself, though!
>
> I'll leave commitments of resources to Brett, but I'd bet we will want to get
> involved in at least one of these projects. We started on an inhouse
> solution for stashing blobs in arbitrary external stores, but it didn't get
> beyond requirements and a pretty rough set of interfaces. (Hi, Chris
> McDonough! It's been far too long since we whinged at each other. Also, hi,
> Kibo! I don't know you.)

I'd try helping with the ZODB blob support first; it's the right level
to solve this problem.

>> CMFEditions will be part of Plone 3.0. If you can help test it and make
>> it as robust as possible, this will likely be a very good use of your
>> time, since you'll benefit from it being part of the core.
>
> It's certainly not an easy problem, and I'd be thrilled for it to be not-mine.
> I will see if I can't integrate the standalone Product into our application
> next week. We are presently targetting Plone 2.5, it'll likely be some while
> yet before we move to 3.0.

That's cool; CMFEditions works on 2.5, though I believe trunk is for 3.0
now, but not much has changed.

>>> Document signing -- The content in our application is typically edited
>
>> Plone 3.0 will (almost certainly) ship with 'iterate' by Kapil as a
>> staging solution. This builds on CMFEditions and is apparently quite
>> simple (though I've not had a chance to look at it myself yet). I'd
>> recommend you try to plug into this if possible.
>>
>> Iterate also needs a bit of last-five-percent work before it's merged,
>> so now is a good time to pick up on this.
>
> I'm not certain this is actually what we are after. The sort of document
> signing we're after is PKI-based.

Right, I think I misunderstood.

> Most of it will happen outside of Plone.
> What we'd like to add to Plone is the ability to verify signatures, possibly
> to manage public keys, and maybe even give Plone itself the ability to
> digitally sign documents in the rare case that it mutates them. I think you
> were confused by my poor description into thinking we wanted to enhance the
> review facilities provided by Plone, but really we want to use PKI to allow
> some of the workflow to happen outside of Plone, to better fit our customer's
> existing methodologies. Plone would peel off and validate successive signed
> envelopes to figure out what has happened to a document since it was last
> checked in.

That sounds very interesting if it can be done generically. I don't
fully understand the use case, though, so I can't offer much more advice.

> Or something. This is all very tentative and based on a couple of bullet
> points from a meeting I didn't attend. ;-)
>
>> Right, that's great. I think having two separate packages [ContentHistory,
>> CMFEditions] makes sense.
>
> I sort of presumed that as long as you were tracking historical states of a
> document, it would be a good place to start to also provide reporting on the
> history of a document. But not having looked at CMFEditions yet, I could be
> way off base. I do not mind keeping ContentHistory separate.

Right, you may be able to get some of the information out of
CMFEditions, but the two don't have to be one single product.

Auditing lends itself to working on the basis of event handlers. If you
listen for events like IObjectCreated and IObjectModified then you can
log all of that in a single place (say a local utility). Some events may
come out of the versioning solution, but it's just a different listener.
The point is that CMFEditions won't necessarily be involved on every
edit (if, say, you have explicit versioning).

>> Are you using Zope 3 events to listen for object created, modified etc?
>> In Plone 3.0, at least, the sending of events will be better and more
>> predictable.
>
> Yes, and that is good to hear, but we have to support at least late versions
> of Zope 2.

No, no, no.... Plone 3 will run on Zope 2.10; but Zope 3 events are
usable in Zope 2 right now (also in 2.9 and Plone 2.5).

> I have noticed a few cases where I have not received the events I
> was expecting, and I'm afraid I'm going to have to make history logging
> voluntary in these cases. Obviously much rather not. Its not such a big
> deal for us since we only support the content types we have written so we can
> make the required calls to ContentHistory, but it sure makes it a much less
> generally useful Product.

There are standard events that come with Zope 3 (and thus also Zope 2.8;
I would use Zope 2.9 though, and 2.10 when you upgrade to Plone 3), such
as IObjectModified or IObjectCreated. If you register event handlers for
these, it should work well. If you are missing events, then it may be
they're not being fired (bug or missing feature), but it'll be easier
for you to keep the content history product separate and fix up your own
content types to fire the relevant events if Plone/CMF/Archetypes are
not doing it for you.

See the b-org tutorial on plone.org for more background.

> Thanks for your valuable time and attention, Martin. I understand we've
> already got a couple responses off-list, so things are going well already,
> and we're looking forward to becoming more involved in the future.

Great to hear!

Martin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

Mike Pelletier

Re: Looking for collaborators

Reply Threaded

Just a clarification.

On Friday 08 December 2006 17:52, Martin Aspeli wrote:
> >> Are you using Zope 3 events to listen for object created, modified etc?
> >> In Plone 3.0, at least, the sending of events will be better and more
> >> predictable.
> >
> > Yes, and that is good to hear, but we have to support at least late
> > versions of Zope 2.
>
> No, no, no.... Plone 3 will run on Zope 2.10; but Zope 3 events are
> usable in Zope 2 right now (also in 2.9 and Plone 2.5).

Excuse me, I read that "Plone 3" as a second "Zope 3". Yes, we are using Zope
3 events. However, it seems to me (or at least to my potentially buggy code)
that events are not emitted in all cases that you would expect them to be in
Zope 2.9. For instance, I haven't been able to detect certain edit
operations. I'll file a more specific report if you think it would be
useful, I just assumed that event support was incomplete in Zope 2 and it was
an ongoing project.

Mike.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

Martin Aspeli-2

Re: Looking for collaborators

Reply Threaded

Mike Pelletier wrote:

> Just a clarification.
>
> On Friday 08 December 2006 17:52, Martin Aspeli wrote:
>>>> Are you using Zope 3 events to listen for object created, modified etc?
>>>> In Plone 3.0, at least, the sending of events will be better and more
>>>> predictable.
>>> Yes, and that is good to hear, but we have to support at least late
>>> versions of Zope 2.
>> No, no, no.... Plone 3 will run on Zope 2.10; but Zope 3 events are
>> usable in Zope 2 right now (also in 2.9 and Plone 2.5).
>
> Excuse me, I read that "Plone 3" as a second "Zope 3". Yes, we are using Zope
> 3 events. However, it seems to me (or at least to my potentially buggy code)
> that events are not emitted in all cases that you would expect them to be in
> Zope 2.9. For instance, I haven't been able to detect certain edit
> operations. I'll file a more specific report if you think it would be
> useful, I just assumed that event support was incomplete in Zope 2 and it was
> an ongoing project.

That probably means Archetypes isn't doing what it needs to. The
situation in Plone 2.5 is not ideal, you may want to have a look at what
Archetypes trunk does. But you can use at_post_create_script() and
at_post_edit_script() to do no