email management

[Rodolphe]

I am a bit stuck on the integration with the email client.
My first quick trial to drag&drop an email from outlook downto my swing GUI showed me that I was easilly getting some fields of the email. This made me quite confident that with some deeper investigations, I could get the other informations (essentially the email body + the attachement).
But now that I have tried to investigate further, I realize that I cannot get more than the fields that are displayed in outlook.
Here are the different alternatives I have in mind and their status:

• my first idea was to manage a "unique id" of the email and keep it in the email client. And then use an API like moyosoft which seems to be able to manage an email id to access the email. But this solution has got several drawbacks:
1. how can I get this "unique id" from a drag&drop of the email from outlook into PDM GUI, or cut/paste ?
2. this "unique id" would be specific to each email client. I want to integerate with several email clients and to minimize as much as possible the specific code required to integrate with the applications

• then I have looked at Google Desktop behaviour. For email indexation, GD simply seems to parse the .pst file and to duplicate the content of all the emails in it's own structure (that probably a reason why it uses so much room on my hard drive). The indexed emails can only be read in GD GUI (in html in your favorite web browser), but you cannot open it in it's native application anymore.
  So, I think I can also extract the email from the email client (when the user puts it in PDM) and keep it as a .msg file (for outlook) in my internal structure. Then, I could re-open it (even if it's ) in it's native application using jdic, as I do for files. And that's what I am trying to implement now. But I am stuck:
  
• with outlook, as described above, I cannot get the content of the email that is added in PDM
• I have tried several other email clients:
• thunderbird does not seem to support drag&drop and file storage of emails
• columba does not support drag&drop
  

The only alternative I see is to take a java open source email client (like columba) and to modify it to work as expected ...

Any other/additional ideas ?

Remark: I have planned to provide a soap API to access PDM features, in order to provide means to integrate into other applications.

Rodolphe

[Jules]

Hi,
I'm not in to your purpose of having the mail saved as file, and then
read it's fields.
The only thing I know is that saving an email with MailToFile results
in an msg containing all usual e-mail fields in the dso-fileproperties.
Maybe thats enough for you. You don't need to open the msg, just read
the file properties. MailToFile only works in Outlook..
(www.mailtofile.com/en/)
Will this help you?

[Rodolphe]

Hi,
I don't really understand what is the difference between MailToFile and the standard drag&drop of an outlook email into a folder in the windows explorer, and how it could help me inside my java program.
I have asked for a demo version in order to see.
What I would like to do is: when an email is dropped on a "folder" in PDM UI, store a copy of the email in a file (this would not be shown to the user) in a private PDM place (as Google Desktop does). Thus, I could be able to re-open the email copy in outlook (the user will think it is the original email).

Thanks anyway for this suggestion
Rodolphe

[Jules]

I thought the interesting difference for you should be the
DSO-fileproperties. An email saved with mailtofile has filled
fileproperties, a drag and dropped file doesn't has those. This
implicates you can read the sender, receiver, date/time, etc. without
opening the email in Outlook.

For DSO in java, see
http://tomcat.apache.org/tomcat-3.3-doc/mod_jk-howto.html
http://www.dbmsmag.com/9803d14.html
http://www.developerfusion.co.uk/show/5093/

[Rodolphe]

Hi Jules,

Although DSO fileproperties seems to be an interresting concept that could be useful for my project, it is not my priority for the moment. The point is that I don't see how I could take benefit from MailToFile to reach my first goal : save an email in a .msg file -transparently for the user- when an email is dropped into my java UI. MailToFile offers a nex button in outlook to save your file  in an external file. I don't want the user to perform this action himself, but I would like to hide it. I want the user to have the feeling that he has just created a reference (shortcut) of his email in PDM, and afterwards, when he will open the email from PDM, it will open the email (the copy, but the user will have the feeling that it is the original one) in outlook.

Rodolphe

[Jules]

Hi Rodolphe,
In case the MailToFile dialog doen't appear, all emails will be saved
in the same directory, with a default generated filename (based on the
subject, sender, and date/time of the e-mail).
Would it help you if MailToFile after saving the msg initiates an
import action for your java UI? Do you have an executable of api which
can be called by an external application?
Or is your application able to scan a directory, discover any new files
and import them in your java UI?
Jules

Rodolphe schreef:

> ------=_Part_27987_7784548.1159391387998
> Content-Type: text/html; charset=ISO-8859-1
> X-Google-AttachSize: 1780
>
> Hi Jules,<br><br>Although DSO fileproperties seems to be an interresting concept that could be useful for my project, it is not my priority for the moment. The point is that I don't see how I could take benefit from MailToFile to reach my first goal : save an email in a .msg file -transparently for the user- when an email is dropped into my java UI. MailToFile offers a nex button in outlook to save your file&nbsp; in an external file. I don't want the user to perform this action himself, but I would like to hide it. I want the user to have the feeling that he has just created a reference (shortcut) of his email in PDM, and afterwards, when he will open the email from PDM, it will open the email (the copy, but the user will have the feeling that it is the original one) in outlook.
> <br><br>Rodolphe<br><br><div><span class="gmail_quote">On 9/22/06, <b class="gmail_sendername">Jules</b> &lt;<a href="mailto:mpvj...@hotmail.com">mpvj...@hotmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> <br>I thought the interesting difference for you should be the<br>DSO-fileproperties. An email saved with mailtofile has filled<br>fileproperties, a drag and dropped file doesn't has those. This<br>implicates you can read the sender, receiver, date/time, etc. without
> <br>opening the email in Outlook.<br><br>For DSO in java, see<br><a href="http://tomcat.apache.org/tomcat-3.3-doc/mod_jk-howto.html">http://tomcat.apache.org/tomcat-3.3-doc/mod_jk-howto.html</a><br><a href="http://www.dbmsmag.com/9803d14.html">
> http://www.dbmsmag.com/9803d14.html</a><br><a href="http://www.developerfusion.co.uk/show/5093/">http://www.developerfusion.co.uk/show/5093/</a><br><br><br>
> ------=_Part_27987_7784548.1159391387998--

[Rodolphe]

Hi Jules,
It seems that you are interrested in selling me your product, aren't you ;o)
I am interrested in reproducing the behaviour provided by MailToFile (save an outlook email in a file), but inside a java application. The main reason for it is that the action that will launch this behaviour does not happen in outlook, but in my java UI (drop of the email downto a PDM folder). So I think it should not be MailTofile to call PDM, but the opposite. And in this case, PDM should also provide an identifier of the email to store (I don't know how to build this id).
To fully answer your question, I plan to provide a soap API inside PDM in order to allow it's integration inside an application.
Rodolphe

> Hi Jules,<br><br>Although DSO fileproperties seems to be an interresting concept that could be useful for my project, it is not my priority for the moment. The point is that I don't see how I could take benefit from MailToFile to reach my first goal : save an email in a .msg file -transparently for the user- when an email is dropped into my java UI. MailToFile offers a nex button in outlook to save your file in an external file. I don't want the user to perform this action himself, but I would like to hide it. I want the user to have the feeling that he has just created a reference (shortcut) of his email in PDM, and afterwards, when he will open the email from PDM, it will open the email (the copy, but the user will have the feeling that it is the original one) in outlook.
> <br><br>Rodolphe<br><br><div><span class="gmail_quote">On 9/22/06, <b class="gmail_sendername">Jules</b> <<a href="mailto: mpvj...@hotmail.com">mpvj...@hotmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

[jules Van Joules]

Hi Rodolphe,
I'm trying to understand your problem, and my interest is to help you, as
far as i am able to.
I don't know anything about java and i tried to understand the aim of the
p-d-m group / your application.
Do you mean an email has to be moved from your javaUI to Outlook? I am
getting confused now.
Can you provide some pictures or a movie of your javaUI, or of do you have a
white paper, or description?
Jules

_________________________________________________________________
Live Search, for accurate results! http://www.live.nl

[Rodolphe]

Hi Jules,
Thank you for your interest in PDM.
The concept is described on the home page. I have put some screenshots and a proof of concept (you need to have java JRE 1.5 installed).
The darg&drop is from outlook to PDM, in order to create add a data (in fact a data reference) in a folder. Once the data is referenced in PDM, a double click (or "open action) opens the referenced data (in our case, an email) in it's native application (in our case, outlook). It is comparable to Google Desktop, except that instead of parsing all the emails/files/other data that are stored on the computer, the "data referencing" is performed manually.
Let me know if it is not clear. I could add a movie if necessary.
Rodolphe

[jules Van Joules]

Hi Rodolphe,
With pdm you want to gather information about all sort of files? Just drag
and drop the file to the pdm system and the pdm files the information?
In fact the user saves the file in the usually directory, then use the drag
and drop method to let the pdm system know about this file? Did I understand
it right?
I suppose you can register one file more times?
What happens when the users moves the file? Does the pdm know about that?
What if the user want to add more information in the pdm, eg importance, how
many years to keep the file, etc.

Did I understand it right?
And why are we the only one in this group?
Jules

>From: Rodolphe <rde...@gmail.com>
>Reply-To: p-...@googlegroups.com
>To: p-...@googlegroups.com
>Subject: Re: email management
>Date: Mon, 2 Oct 2006 21:02:14 +0200
>
>Hi Jules,
>Thank you for your interest in PDM.

>The concept is described on the home page <http://p-d-m.sourceforge.net/>.

_________________________________________________________________
Play online games with your friends with Messenger
http://www.join.msn.com/messenger/overview

[Rodolphe]

Hi Jules,

my answers are in the text

On 10/20/06, jules Van Joules <mpvj...@hotmail.com> wrote:

Hi Rodolphe,

With pdm you want to gather information about all sort of files? Just drag
and drop the file to the pdm system and the pdm files the information?
In fact the user saves the file in the usually directory, then use the drag
and drop method to let the pdm system know about this file? Did I understand
it right?

The idea is to reference not only files, but any kind of information (email, bookmarks, but also any "application specific" information; could be a chapter inside a word document, a cell of an Excel spreadsheet, ...)
I can be seen as a generic folder manager for any kind of application. It can be a autonomous tool (best approach if you want to manage all kind of data in the same folder structure), or why not an API that can be accessible though SOAP.

I suppose you can register one file more times?

That's one of the advantages of this concept. Same as GMail "labels".

What happens when the users moves the file? Does the pdm know about that?

That is one of the issues to solve. I  don't know if it is possible (and not too much CPU consuming) to have a kind of background listener to notify pdm when a file is moved. Same with all other type of informations. But If you start using pdm, you're supposed to move your files less often. You could eventually store all your files in one single folder and only use pdm ...

What if the user want to add more information in the pdm, eg importance, how
many years to keep the file, etc.

You're right pdm can be used to "tag" the referenced data with any kind of metadata that can be used as search criteria.

Did I understand it right?
And why are we the only one in this group?
Jules

Because you're the only one that has subcribed :o) How did you arrive on this group ? Just by chance ?
I have mentioned  this project (the sourceforge link) in some java oriented distribution lists but it does not seem to attract a lot of people. More support would probably give me some motivation. Or perhaps it needs to become more concrete before people can adhere.

What do you think of the concept ? Don't be affraid to be sincere ...
Rodolphe

[Jules]

Hi Rodolphe,
I arrived on this group because I am very interested in a user friendly
way of archiving. User friendly means to me all users can work with the
software without much effort. Another general word for this software is
Performance Support Systems: The system (software) supports the
performance of the user in a perfect way.
In fact working on a computer means continuous archiving. For every
electronic document the user needs to think where to put it. Of course
archiving all documents in one directory, but tagging every file feels
good to many individuals. I don't beleave this is a good concept for a
company.
Besides it's too difficult to get a good view of the search results.
This is the same problem I have with the search engines on the
internet. You will always have a number one search result, not meaning
it's the best result.
Your pdm is driven by technic. Of course, you (we) are developing it.
A java programmer will not be more interested in pdm because you
develop it in java. If you want to get success on this programm you
need to know how a user would like to handle the problem. Do you know
somebody having this archiving problem (beside yourself)? And if you
know, would he be hapy with this way of archiving?

I would be!
But I would be very concerned about the effort I have to do archiving
every document, bookmark, excel cell, word sentence.
And I am concerned about the technical consequence of your promiss. Can
you be sure all my tags will be kept? E.g. when i tag a sentence in MS
Word, this sentence can be changed, deleted, moved, the document can be
moved, deleted, never saved at all!

This makes your idea a mission impossible. Or a challenge?

[Rodolphe]

Very interresting conversation.

In fact, before starting this project, I discussed the concept with several people around me, using a computer every day for different tasks (secretary, manager, developpers, designers, ...) working in a big company. And as you mention, they are often faced to this very basic problem: where did I put this mail, or this file. Is it in a folder in outlook?, did I put it on the drive?, did I detach the document from the email?, ... I also realized that some data need to be referenced several times in different contexts. What we use in our applications to materialize the notion of "context" is generally a folder. And thus, we manage our data using a folder tree. With 2 main limitations: when a data is in a folder, it cannot be in another; each application provides it's own folder tree, and so, we create almost the same folder organization in each of our applications.

There is another solution provided by google (and similar by other companies) called Google Desktop. It indexes all your data. But although it is sometimes helpfull, it does not remove the need to archive the data in a special place.

That's why I came to this idea: keep all the data in one single place and manage them by reference, in one single tool for all kind of data. This would also provide the capability to "anotate" the data with metadata (or tags). Add to this the batch indexing feature of Google Desktop (not only on content data, but also on the added metadata), and you have good chances to find your data easilly when you need it.

I imagine that this feature could be provides at the OS level. The hard drive would not be organized in folders and this tool would be the common tool for all data management. There would be no need to move the data (just remove or move a reference). If you want to remove the data physically, you could ask confirmation for physical removal when the last reference on the data is removed.

I agree that the reference on lower level data (such as a word chapter) is not very clear to me. As you say, what happens if the chapter is removed. It just came from the need that you may have sometimes so reference a data more precisely than just referenceing the file. A specific transparent of a huge powerpoint presentation for exemple.

So, as I'm not working for microsoft, the only thing I can do is develop a tool that illustrates the concept. I agree that if you still manage your data in folders, it makes some confusion to anderstand the concept, and probably to use the tool.

To share my idea, the first occasion I had was when I started developping it. I asked a technical question on a java developper list and took the occasion to present the concept. Hopping that there would be some reactions. But sadly, I got no answer on the technical question, and no reaction on the concept.

That's why I am happy to have this discussion with you here.