Hello, On Mon, Sep 29, 2014 at 11:55 PM, Kis, Zoltan <[email protected]> wrote:
> Hello, > > Thank you for listing these requirements. Based on these, IMHO > email-service is not the right solution, and we need to look at a more > complete solution like EDS/Camel, plus Bluetooth MAP/PBAP support. > Included Srini for the discussion. > I used to maintain Evolution & EDS upstream. I wrote Camel Email Factory [2], which provides email as service over IPC(DBus). I also have a Camel MAP Provider [1] which provides Bluetooth/MAP support for the Email factory to transparently support bluetooth connected phones. Some work in definitely needed on the settings interface/app to enable email when the phone is connected to let the Email Factory to use the connected phone. > > We need to start simple, first get account setup/sync for car users > and managing seat-user mappings. > > We also need to update > https://wiki.tizen.org/wiki/Multi-user_Architecture#Multi_User_use_cases > > Apart from these, basic email use cases could also be solved using web > apps/stacks. > > Best regards, > Zoltan > > On Mon, Sep 29, 2014 at 9:00 PM, Podolyak, Zoltan > <[email protected]> wrote: > > Hello, > > > > In light of the uncertainty surrounding the fate of the email-service > > component, as well as its minimal IVI support, I think it would be > helpful > > to clarify some basic requirements for an email component in IVI. > > > > There's definitely a need for email in the car. Non-drivers could benefit > > from a traditional email app, where text is inputted via a virtual > keyboard, > > similar to how one would use a mobile version. The ultimate solution of > > course would be one where drivers would use a combination of > > Speech-To-Text/Text-To-Speech for interaction with the email app while > > driving. > STT/TTS falls under the purview of the email app, which uses a standard keyboard or voice to type and have option to read out messages/list/folders. The email app would use internally the Messaging API over Email Factory to get to accounts/folders/mails. > > > For a PoC, IMAP and POP3 support is needed at a minimum, as well as > support > > for adding/managing multiple accounts. Pre-set account types such as > > Exchange, Gmail, and Yahoo would also be nice in a production > environment. > Camel Mail Daemon out of the box supports IMAP, POP3 for fetching and SMTP for sending mails. It has support for multiple mail account. It is built over the Camel API which has a provider framework for multiple backends. Camel supports Exchange via EWS, ActiveSync(David Woodhouse maintains it), and MAPI as well as raw IMAP for mails. The mailer daemon was never tested under Exchange but it shouldn't be a hard job. The email app's account configuration can auto-configure accounts based on the email (Google/Yahoo/Live/*). Camel Daemon also supports a new provider I wrote for IVI cases, CamelMAPProvider [1]. It provides a Bluetooth/MAP backend so that the email app can transparently access messages over MAP to the connected phone (Assuming that the phone supports email over MAP - Blackberry, Cyanogenmod) > Most email features such as attachments, searching through mail (voice > > search?), browsing folders, and conversation threads are also preferred > in > > an IVI scenario as well. Obviously, support for push notifications and > the > > like, would do away with the need for things like a giant sync button, > > though a manual sync/refresh would still be nice. > Mail Factory has APIs for Fetching Folder list, message list and messages, etc. It also features a search api, which the email app can invoke on voice search or manual keyboard search for searching mails. IMAP supports Push Messages. Exchange also supports PUSH notification. The email factory also has account settings to check mails on specific interval or api to check/sync mails instantaneously. Conversation/Threading is a email app feature than the mail factory as the camel daemon provides thread-ids for the app to construct threads. > > > We can talk more about the gritty details, but this should give a concise > > overview of what we're looking for in IVI. Thanks for the support! > The email factory source is available at [2] . It was a few months old and I can update once we take this forward actively. Note the email factory is a native code that provides apis over DBus. If we are using Messaging API, there is a task to implement the Messaging API over the email factory interfaces. Also the Camel MAP Provider supports Fetching folders, Messages, and individual mails. It supports marking as read and deleting messages. It supports Sending email as well. But note that the Bluetooth/MAP for email isn't commonly available on many phones (iPhone/Android/Win). I used mostly Blackberry and also testing on Cyanogenmod. Every phone company implements MAP in their own way and we may need to build some logic in the email app depending on the phone that we may need to say "Supported". The task is small but it is important to be noted. If you have any queries, I would be very happy to answer here. Thanks, -Srini. [1] - https://github.com/sragavan/evolution-map [2] - https://github.com/sragavan/e-mail-factory > > > > Regards, > > Zoltan > > > > > > > > > > > > On Tue, Sep 9, 2014 at 10:13 AM, Kis, Zoltan <[email protected]> > wrote: > >> > >> AFAIK the email-service package was not meant to be included/working > >> in IVI, and it's no surprise that it has never worked in IVI. I asked > >> Dominig and Mikko to clarify its fate. If there is interest to make > >> email-service work on IVI, it needs to be synchronized with its > >> creators. I am not maintaining it, but will review patches. > >> > >> Best regards, > >> Zoltan > >> > >> On Tue, Sep 9, 2014 at 7:48 PM, Podolyak, Zoltan > >> <[email protected]> wrote: > >> > Thanks for getting back to me. If I'm going to push to tizen, then > I'll > >> > have > >> > to change some things and test just to make sure everything works. > >> > > >> > I have to say though, the tizen branch seems pretty broken. It is > >> > completely > >> > non-functional with the email-test-app package and it doesn't even > build > >> > properly. It's probably missing some dependencies. > >> > > >> > Anyway, it would be great to know what this package's future is, since > >> > there > >> > are some other issues that I may want to address, but only if it's > not > >> > a > >> > wasted effort. Thanks again! > >> > > >> > On Tue, Sep 9, 2014 at 9:38 AM, Patrick Ohly <[email protected]> > >> > wrote: > >> >> > >> >> On Tue, 2014-09-09 at 08:11 -0700, Rees, Kevron wrote: > >> >> > Ning is correct. Push to the tizen branch. This may require you > to > >> >> > rebase your patch. I don't know about the future of the email > >> >> > service. I'm adding Patrick who might have some insight. > >> >> > >> >> Sorry, I can't help with email. That's part of the "Messaging" > domain, > >> >> of which Zoltan Kis (on CC) is one of the domain architect on the > Intel > >> >> side. Perhaps he knows who maintains that package. > >> >> > >> >> At the moment, it is listed under the "Messaging / Email" subdomain, > >> >> which doesn't seem to have any active maintainers. See: > >> >> > >> >> > >> >> > https://review.tizen.org/gerrit/#/admin/projects/platform/core/messaging/email-service,access > >> >> and > >> >> > >> >> > >> >> > https://review.tizen.org/git?p=scm/meta/git.git;a=blob;f=domains;h=ca47eb13bbde1c6f9819ce6ec49bb90fcaee9e65;hb=refs/heads/master > >> >> > >> >> I doubt that Srini (currently listed in the domains file) really ever > >> >> worked on this and probably never had a Gerrit account, which would > >> >> explain the empty ACL in Gerrit. > >> >> > >> >> -- > >> >> Best Regards, Patrick Ohly > >> >> > >> >> The content of this message is my personal opinion only and although > >> >> I am an employee of Intel, the statements I make here in no way > >> >> represent Intel's position on the issue, nor am I authorized to speak > >> >> on behalf of Intel on this matter. > >> >> > >> >> > >> >> > >> > > > > > >
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
