[TYPO3-ect] flexible DAM-frontend : coding team, ideas, contributions

[Karl-Ernst Kiel]

Hi!

Franz Koch wrote:
> Hi,
> As the topic says, a general DAM-frontent plugin is necessary - or would 
> be a very attractive extension to have.

Yes, definitely!

> - there are too many DAM-'gallery's (and gallerys in general) in TER

And there?s also a bunch of DAM download lists with very similar 
functionalities...

> Here is a quote from myself regaring Jan-Philipp Halles post
> ----------------------------------------
>> as much as I know, Volker Graubaum allready developed a full-featured 
>> DAM-gallery with FE-lightbox, FE-upload and all that stuff. I wrote 
>> him a mail, but didn't get any answer from him. This extension is 
>> allready in productive use for a stock-photo site - but I've forgotten 
>> the name of the site. He mentioned it in a podcast interview of a 
>> german magazin.

I also listened to this podcast and it sounded really interesting.
There seem to be some funny things going on with this commerce 
extension. I personally came to the conclusion that the commerce 
developers had a meeting at the bermuda triangle. (Younger readers may 
have to look at: http://en.wikipedia.org/wiki/Bermuda_triangle :-) )
Seems that some of the developers and/or the extension code completely 
disappeared...

>> I myself also need a highly flexible DAM-based gallery. What I've got 
>> so far is a flexible extension using DAM-categories, fe-user 
>> relations, adding a BE-DAM selection filter for images by fe_users, 
>> common views (single, search, list), a rather flexible 
>> sorting-mechanism via flexform and fe-upload with DAM-indexing. 
>> FE-uploads are also categorizeable.

Sounds fascinating!

>> It's working - but needs further development. 

O.K. - that?s why we are here...

>> But currently I don't have time to develop it any further.
>> If you (or anybode else) are interested in my current aproach I can 
>> upload and share it to combine man-poweres and finally get a flexible 
>> DAM frontend that can be used for gallerys, downloads or anything 
>> else.

So we "just need another hero" :-) ?!
(Oh - I just feel a bit sick this moment... )
To be true: Would be a fascination task to get something like this 
together but I?m a bit scared of taking it because I don?t know how much 
time I will have to follow this track in near future.

> 
> What I did
> ----------------------------------------
> - posted this :)

Thanks! A good start :-)

> - called Volker Graubaums office today and wait for a response from him 
> as mails didn't work

Did you get any answer yet?

> 
> My wishlist for the extension so far (can't think right now - too tired 
> - haven't slept much)

I found out that this is the real secret of sucessfully developing TYPO3 
related things: Don?t sleep! Just skip it and you have plenty of time to 
write good extensions or simply silly postings like mine.
This lack of time really sucks and is in fact one of the main problems. 
See "face the facts" below...

> What I need from you
> -----------------------------------------
> - feedback / suggestions / ideas

Here I am :-)

> - support of the ECT (if it fit's in their plan)

Hey - what?s this ECT about? I?m not very deep into the structures of 
the TYPO3 Community and I can?t find a team page on 
http://typo3.org/teams/ so - who/what/where is it or is it simply this 
newslist? Extension development coordinations sounds like a very 
reasonable task. (And that?s the reason we are writing in this list and 
not in the DAM list.)

> - cooperative development of that (building a team)

Yes, I really like to join but at first I?ll have to check my personal 
resources.

> - oh, and money is always welcome ;) - but I have to say I'd rather like 
> some contribution

Here is my point of view to some aspects:

One Universal vs. many specialised extensions
---------------------------------------------
Looking at the requirements there seem to be two main directions:
- having picture galleries
- having download lists
This two fit together quite good.

But there are (or will be) more requirements like:
- having a shopping basket
- a voting system
- secure downloads
- a music library
- video downloads with DRM
- ...

So having a "one size fits all" solution may be attractive. In fact this 
size would have to be XXL and you?ll often have to wash it at high 
temperature to shrink it down to your needs.
I think tt_news is this kind of extension. It?s well featured, fully 
documented and stable but in some (many?) cases I would prefer a more 
"light-weight" solution.

The drawback of lightweight and specialised extensions is that there 
will be too many too fast. (That?s the situation is with dam fe-plugins 
or calendars these days.)

Franz Holzingers idea to provide a DAM FE library extension sounds very 
interesting, too. I?d like to see this library getting integrated into 
the DAM core.

What could be a starting point?
--------------------------------
Options:

1) Build a completely new extension, based on DAM 1.1

2) Use an existing extension - but which one?
- Your description of your own extension sounds very good - I?ll have a 
look at it
- The "Graubaum-DAM-Thing" also sounded interesting, but there is this 
"bermuda thing"...
- I (and many others as I discovered recently) used dam_downloads as a 
basis and did some improvements (e.g. Martin Baum did some interesting 
extension-extensions)
- I don?t know much about the other dam FE extensions. mm_dam_filelist 
sound interesting but I did not manage to test it yet.


Maybe this could be a course of action:

- collect wish-lists
- examine existing extensions and extract "best practices"
- wait for DAM 1.1 to be finished and use API as much as possible
- start building a new extension aiming to fulfill the "top 50% of the 
wish lists" and provide many hooks to enable other extension to build on 
this "master DAM FE extension"
- while building extract the core functionalities and put them into a 
seperate "FE library extension"
- ask René Fritz to integrate this "FE library extension" into DAM 1.2 
so that the functionality will become part of the "DAM core" and the 
library will get obsolete

In "the end" (better say: when reaching a mature version) we could have:
- a DAM 1.2 with mighty FE API?s
- a general DAM FE extension, covering the most common tasks
- some exensions for special requirements that build upon this DAM FE 
extension


Face the facts
--------------
I planned to write down some thoughts about the difficulties of 
development (not only programming aspects but mainly social aspects and 
lack of resources etc.) and how it might be possible to avoid common 
pitfalls but for now my personal resources are empty. I just have to get 
to sleep. Just facing the fact that the "skip sleeping" method sounds 
very promising but is in fact not working. Like so many other concepts...

So I close with a
"To be continued..."

Greetings,
Karl-E.