ES vs FSS

Hello Cyrille, Sidnei,

As, I promised you , I give you the list of FileSystemStorage advantages.

I'll do a brief comment one each item and then assing a sign to show where ES is currently better (+), worse (-) or equivalent (=).

- Copy/Paste or Cut/paste operation does not consume any memory because file is not stored in a volatile attribute.

ES is expensive when doing copy/move operations, as it stores all data inside Zope objects (ouch!) during these operations. (-)

- One undo operation is authorized. 2 cases: delete the content of a field and undo, delete a content and undo

ES has no undo support. (-)

- Use of FileSystemStorage with ImageField

ES is Field independent (it's only a storage). (+)

- Use of StreamIterator when downloading file

ES also uses StreamIterator. (=)

- Plone wide side: you can configure paths for each plone instance

ES has no UI at Plone side. (-)

- When getting value on a FileSystemStorage field it only returns a class
inheriting from OFSImage.File or OFSImage.Image or just return basic
text.

Exactly the same... :-) (=)

- Maintenance tools

ES has no maintenance tools. (-)

- Files or images are not wake up when just getting size, content_type
and file name

I guess it's waking up, just not have the content read from filesystem as you probably store size/content-type/filename as attributes. ES does the same trick. (=)

Now let me list a few points:

- ES has high flexibility when defining storage paths. It has a default setting where the storage path reflects the portal structure. IOW, when the type's schema has only one field with a ES storage, the filesystem path is the same from portal one, and a file is created. When there's more than one field per schema using the ES storage, a directory with the instance id is created, and files using the field names are used. This can be easily override by defining a proper method in the class.

- ES has a good test coverage. It's far from perfect but covers enough cases to make sure everything is in order, even after radical changes.

What I would to find in the merge of ExternalStorage and FileSystemStorage are :

- Possibility to configure my paths globally or only for a zope instance or only for a plone instance.

Yep.

- Possibility to switch between flat structure filesystem storage or plone mirror filesystem storage

I'd like to say that creating a pluggable way to 'structure' the site is the way to go. I realy like the approach that ATManagedFile is using.

BTW, it would be great if ATManagedFile also can be merged into this yet-to-be-merged filesystem killer product. What do you think Sidnei, any word here?

It would be possible to have ATMF merged with ES and FSS into a single product, maintained by all of us (and everyone that also wants to help) and being able to fullfit our different use cases?

Any advice/remark?

- Better copy/cut/paste support without using ugly fixes

Yes, yes, yes... definitively!

I hope you enjoy and you'll do a great product.

Yep, that's the idea... ;-)

Nate Aune told me he was very interested in this.

Nate, as always, is our übber-tester-guy... :-)

Now, depending on Sidnei's reply, we can define a roadmap to get an estimate about how long this merge can take and also the direction that we want to go...

Hopefully we also can raise some funding to make this happen even faster... ;-)

Cheers,

Dorneles Treméa