RE: [cms-users] Enhanced CMS 0.02

[Alexandre G. <gr...@in...>]

Hi Roger,

I've just taken a look at your installation of CMS. I must say I like
the ability of haveing a file being auto-reserved when uploaded. I'll
soon add a configuration option to have that (or not).

I will also look into implementing a .readonly flag on files that could
be set by an admin or the owner of the file (implies a .owner file).

As far as RCS goes, I have a couple ideas on a version control system
for CMS. Since most of the files stored on a typical CMS installation
will (IMHO) be binary files and not text files, I don't currently have
plans to use a VCS that has the diffs/patches functionnalities. There
would be a simple way of implementing it without third-party software
(thus still keeping an out-of-the-box complete functionnality of CMS).
To try and explain it, the idea would be that, when a file is uploaded
(or shall we say updated), the current file is renames to:

thefile.doc.<date-of-the-previous-file-in-seconds-elapsed-since-1970-or-
something-like-that>.v

This way, it is very easy to list all the version of a given file up to
the current one, with dates at which each was checked-in. A separate
window could list those, and also allowing an admin to delete previous
versions to free up some space.

In the meantime, feel free to test the CVS version and report the bugs
you come accross as we near a stable release version.

Alexandre Gravel
Infivia Solutions
gr...@in...
http://www.infivia.com
//solutions internet //d=E9veloppement web //h=E9bergement =
//consultation
=20


> -----Original Message-----
> From: cms...@li...=20
> [mailto:cms...@li...] On Behalf Of Roger Buck
> Sent: 22 f=E9vrier, 2002 21:20
> To: cms...@li...
> Subject: Re: [cms-users] Enhanced CMS 0.02
>=20
>=20
> Alexandre Gravel wrote:
> >=20
> > Hi Roger,
> >=20
> > We are very well alive and up to work on CMS 0.03.
>=20
> Great!
>=20
> [--snip--]
>=20
> > Roger, feel free to forward me the code you have, even send=20
> it to the=20
> > cms-devel mailing list, join in, we are never enough at working on=20
> > those projects. The more input and suggestions we get, the=20
> better the=20
> > end product can get.
>=20
>=20
> OK - Well, I have set up a demo cms and placed a tarball of=20
> the demo site (cms-demo.tgz) there. I'll risk running as-is=20
> for next couple of days in case anyone wants to take a look.
>=20
> The changes are mostly cosmetic but might help to explain the=20
> following:
>=20
> > 2. How about having a buttton to  "reserve" and "unreserve"=20
> files in=20
> > addition to current "checkout" and "available". This would=20
> allow files=20
> > to be better protected. For example, a file could be "reserved" by=20
> > default when uploaded. It would be better still if a file=20
> owner could=20
> > make a file "read only" but the "reserve" option would be=20
> easy to  do?
>=20
> William McKee wrote:
> I'm not sure I understand the need for a reserve function but=20
> haven't implemented CMS in a production environment yet so=20
> may just be overlooking the obvious. At any rate, if this=20
> option is added, it should be optional to have it "reserved"=20
> by default.
>=20
> Unless the file is reserved, then any user may (IMHO) too=20
> easily delete. If the file is auto "reseved" on upload, then=20
> this offers some protection against accidental delete?
>=20
> Alexandre Gavel wrote:
> It would also be pretty to implement the read-only flag=20
> through a thisfile.doc.readonly control file. I'll have to=20
> add that to my wishlist. The thing is though that since we do=20
> not have a definite authentification module, it would hard to=20
> determine who can and who can't set the readonly flag on a=20
> given file. Matti, how about having an admin password and a=20
> user password for the desktops? That could set some flags and=20
> allow more or less options to the user.
>=20
>=20
> What I was thinking was that each user should be the=20
> administrator of their own file(s); Whoever first uploads a=20
> file becomes the administrator of that file? Currently I=20
> think this is flagged by using email address? If so, then the=20
> email address is already functioning as a kind of insecure=20
> "password"? Maybe that could be made more secure and be given=20
> extended functionality?
>=20
> > 3. Have you thought about using RCS  for revision control? I think=20
> > this would be easy to do ( you could take a look at one way that is=20
> > done at http://www.twiki.org/ ).
>=20
> William McKee wrote:
> Similar opinion here. I like the idea but I don't want to be=20
> forced to use RCS or CVS.=20
>=20
> Understood.... but I think RCS may be OK - I think it is=20
> almost universally distributed and widely used as a "simple",=20
> time saving and robust " plugin"... even the Python FaqWiz=20
> uses it as a plugin... and I doubt they'd have taken that=20
> decision lightly :^)
>=20
> William McKee wrote:
> Furthermore, there's a serious problem with storing binary=20
> files in CVS, IMHO. CVS (and I presume RCS is the same)=20
> doesn't do diffs between binaries. Thus each time a file is=20
> added, the entire file is added. If you're supporting users=20
> who share large PowerPoint presentations or Word documents,=20
> you're going to eat up some serious diskspace and,=20
> potentially, incur substantial additional storage costs.
>=20
> Agreed - I guess I was looking at this as being primarily for=20
> purpose of backup security (as in the sense of a primarily=20
> file distribution - not primarily a devlopment environment). =20
> Wouldn't that require a separate VCS over and above what CMS=20
> is designed to provide?
>=20
> Anyhow, I do agree with all your comments and I'm glad you=20
> mentioned storage space issue - is there any intention of=20
> setting simple cms user quotas?
>=20
>=20
> You're welcome take a look at a test setup here (I'll place=20
> code there also - see "cms-demo.tgz" ).
>=20
 http://www.saas.nsw.edu.au/cgi-bin/cms/index.cgi?login=3D1


Demo login details:

   Folder name: desk1
      Password: client1

One other thing while I think of it: Every time a significant change is
made, although in general I don't like "push", it would be nice if cms
auto-refreshed the client's browser display (say after a new file upload
etc)?

R.

_______________________________________________
cms-users mailing list
cms...@li...
https://lists.sourceforge.net/lists/listinfo/cms-users