CMIS

[jadjay]

Bonjour,

Merci pour le travail effectué ça déboite !

Je pense que le plus urgent pour que ton projet prenne de l'intérêt rapidement (voir TRÉS RAPIDEMENT) c'est d'incorporer un client CMIS (http://fr.wikipedia.org/wiki/CMIS).

Si Paperwork intègre CMIS il sera directement compatible avec les principaux GEIDE du marché (Alfresco, Nuxeo)... Et ce sera l'outil ultime pour que les SSLL (SSII) puissent proposer des outils de scans Open Source.

La publicité sur un outil opensource intégrant un scan/ocr + CMIS le tout facile d'emploi, va clairement augmenter rapidement le nombre de contributeurs...

Je ne suis pas développeur, mais intégrateur de solutions open-source et ton projet à un potentiel énorme dans la GEIDE de type TPE/PME/PMI.
L'intégration brute avec un logiciel de GEIDE serait trop complexe mais l'API CMIS est là pour booster l'intégration avec tout les GEIDE compatible (c'est clairement en passe de devenir un standard).

Voilà en espérant sincèrement que tu vas regarder l'implementation CMIS de python : https://code.google.com/p/cmislib/

Cordialement,

[jflesch]

In English next time, please :)

[jadjay]

Je viens de lire les "Issues" :

• l'intégration CMIS t'évite de devoir créer un outil de centralisation
• idem pour les transformation vers pdf/ps/docbook : les GEIDE disposent de ces outils
• l'indexation sera également gérée par les outils de GEIDE (dont c'est le boulot)

A mon avis en terme de développement tu as tout intérêt à développer en philosophie Unix

Écrivez des programmes qui effectuent une seule chose et qui le font bien.
Écrivez des programmes qui collaborent.
Écrivez des programmes pour gérer des flux de texte (xml-rpc), car c'est une interface universelle.

[jadjay]

Ok so thks for the jobs, you rock

I thinks your project will be very populare if you integrate soon a CMIS client to take advantage of the major DMS product
http://fr.wikipedia.org/wiki/CMIS

Python integrate a API cmislib wich cover a lot of basic usage https://code.google.com/p/cmislib/

I'm not a developer but i'm an integrator of opensource solution and a project wich integrate a scan/ocr + cmis with ease of use will be massively used in common with a DMS.

This would facilitate your dev by

• no need to create a centralisation interface
• no need to have pdf/ps/docbook export plugin, DMS already had such tools
• no need to index, DMS are made for this

This would turn your application as a Unix tool

Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams (xml-rpc ;) ), because that is a universal interface.

[jflesch]

First of all, I don't know (yet) what CMIS is exactly. I'll have a look.

In the meantime, I think there are a few points I should clarify:

First, with Paperwork, I'm not targeting enterprises (even small ones). I'm targeting single users. If it can also be used by small enterprises, great. Otherwise, it's no big deal to me. I assume there are much better tools than Paperwork for enterprises (with lightweight clients I guess).
However if Paperwork becomes hard to use for single users then it's a big problem for me. I'll be blunt: I cannot ask single users to install a DMS.

Second, in my opinion, Unix design doesn't work very well with GUI. The 3 rules you quoted are good if you want to flexible and stable programs. The usual goal of GUI is to make things simpler for the lambda user. By simpler, I mean "do what they want the way they want when they want it". Lambda users don't care about flexibility as long as it does what they want. And most of the time they want pretty much the same thing, so flexibility isn't really an issue at all here. But they also want easy-to-use GUI. It's hard, if not impossible, to make a GUI that do one and only one thing and still satisfy this easiness requirement.
Now I don't think it means Unix design is dead. It just mean that nowadays it has another shape : "write programs and/or libraries that do one thing and do it well". This is the principle I'm trying to apply here. This is why I have many dependencies. This is why Paperwork code is split in 2 parts : the backend act as a glue between most of the dependencies, the frontend gives a GUI to the user.

Third, DMS are themselves not exactly what I would call Unixy ... :)

[jflesch]

By the way, just to be clear : It doesn't mean at all I'm against your idea. It just mean I'll have to look at what CMIS is, and what it can bring to a lambda user.

[jadjay]

"Third, DMS are themselves not exactly what I would call Unixy ... :)" you're totally right :)

"It doesn't mean at all I'm against your idea. It just mean I'll have to look at what CMIS is, and what it can bring to a lambda user." Well i'm not sure it brings anything to them... DMS would act as a backend, which are good for indexing, export in different format, that's all...

"I assume there are much better tools than Paperwork for enterprises (with lightweight clients I guess)." Cite one for me which is open source and ease-of-use ... :D

Your client would be great in enterprise, and the CMIS backend could be just a plugin not a must-configure stuff...

In fact the best way to convince you is to have a try :

• install alfresco with the bundle in a virtualbox instance
• get the libcmis python module, and try this howto https://code.google.com/p/cmislib/wiki/QuickStart

If you're not convinced after that : I owe you a beer :)

[jflesch]

Just so you know : I will have a look, but I won't have much time this week (week-end included), so it will probably have to wait for the end of next week.

[bignaux]

Another interesting stuff is https://en.wikipedia.org/wiki/OPDS. Calibre has is OPDS server ( http://manual.calibre-ebook.com/cli/calibre-server.htm ) .
@ jadjay OPDS is atom feed based too, should be easy to write alfresco plugin to support.

[jadjay]

Well It's publication stuff not communication, you can't send data from
a process to another using OPDS, it's just a kind of blog system using atom.

Not very interesting for ECM, except if you want to publish your data to
a blog...

The killer feature nowaday in ECM is http://fr.wikipedia.org/wiki/CMIS

Your paperwork with CMIS is a bank robbery ! This stuff will smash
businesses by simplicity and low cost...

Don't pretend you don't understand that :)

Jérôme Avond - aka jadjay
Agitateur chez Alolise depuis avril 2005

mail/jabber
: jerome.avond@alolise.org

téléphone
: 0661469785
Le 04/10/2013 14:07, Bignaux Ronan a écrit :

Another interesting stuff is https://en.wikipedia.org/wiki/OPDS.
Calibre has is OPDS server (
http://manual.calibre-ebook.com/cli/calibre-server.htm ) .
@ jadjay OPDS is atom feed based too, should be easy to write alfresco
plugin to support.

—
Reply to this email directly or view it on GitHub
#146 (comment).

[bignaux]

@jadjay as Consultant Logiciels Libres chez Axolys SS2L, are you interessting to do business on this feature with me ? I'm open for new position this days.

[jadjay]

Hum you pick my interest :) Unfortunatly I'm a bit busy those months,
but yes i'm really interested to work this out with you,

I'm thinking loud :
The perfect clients are middle company, with secretaries and a low cost
network, the gold pieces are brand new affairs which search for a good
system.
The product is a ECM "open source" alfresco by default but nuxeo has
interests, and your paperwork stuff which will delight classic mail
transmission,
We need a work out of the box virtual machine, and your client.

Your client need to be able to work both on disk, and being able to send
to an ECM via CMIS, 2 way of doing this and implementing both would be
better : synchrone and asynchrone. (SYNC) Scan and send direct, (ASYNC)
scan and save and send daily, weekly or monthly what had been scanned.
Now you can touch tiny, middle and big business. tiny business doesn't
need a ECM like pw does actuelly, middle have low message to send so
SYNC is OK, and big business need ASYNC for big contents.

CMIS is not really complex you just need to understand xml-rpc
principle, thus SOAP extension (in fact normalisation), and the CMIS is
a normalisation of SOAP functions dedicated to ECM actions. The
manipulation of those objects is quiet simple : CRUD + versionning
(lock/keep lock/unlock/new version).

I could help you but not before the end of november... So I'll take news
at 15th of november. Allright ?

Regards,

Jérôme Avond - aka jadjay
Agitateur chez Alolise depuis avril 2005

mail/jabber
: jerome.avond@alolise.org

téléphone
: 0661469785
Le 04/10/2013 15:20, Bignaux Ronan a écrit :

@jadjay https://github.com/jadjay as Consultant Logiciels Libres
chez Axolys SS2L, are you interessting to do business on this feature
with me ? I'm open for new position this days.

—
Reply to this email directly or view it on GitHub
#146 (comment).

[bignaux]

great news on this subject http://ecmarchitect.com/archives/2013/05/24/1819
CMIS 1.1 now support AtomPub with JSON as data... so better choice.
@jadjay : i'm still waiting for your call, i'm hacking such things this days (on http://ckan.org/ as a modern DMS).

[jadjay]

@bignaux Ok let me know some coordinate so I can call you