Re: [iPAQ] GPE - GNU PDA Environment

On 29 Dec 2001 19:23:10 +0100
Erik Bågfors <erik_at_bagfors.nu> wrote:

> On Fri, 2001-12-28 at 22:09, Nils Faerber wrote:
> > On 28 Dec 2001 21:41:20 +0100
> > Erik Bågfors <erik_at_bagfors.nu> wrote:
> > > Here are my addition to important things.
> > > * Some kind of ipc (xmlrpc/soap/other) corba is to heavy I think.
> > This might be needed. Could you give some example or use-case where we
> > would need this to make it more clear? At the moment I could live
> without
> > it ;)
> Sure. I can even give several. Some things in this short list can be
> done in other ways than ipc, and perhaps ipc isn't even the best but
> anyway.
OK, let's have a look ;)

> * When synchronizing, the application needs to be notified of that or we
> have to make sure that the application is not running. Real time update
> would be best.
OK, I see the need for signalling, i.e. just to tell the application that
some data may have changed. But this does IMHO not imply IPC. A simple
signal should be OK.

> * Interopability. Say for example you are running a todo-application at
> the same time you are running a calendar and you also get the list of
> todo's in the calendar-application. If you then change anything in one
> of them the other needs to be updated.
This is one of the most difficult parts ;)
And it's solved differently in all the systems I know of; most ignore it
completely ;) Epoc32 for example uses a complex object oriented model for
this where you include a object reference into foreign data (i.e. a
contact object inside the schedule application).
I think you are perfectly right to point out this problem and we will have
to find a solution for it. But I do not think that IPC will help here a
lot. Something like a object model or a set of libraries could do almost
the same. If an application wants to import data from another application
it could use a library of the other application to reuse it's code to
get/store the data.
Oh oh ... this becomes complex ;)

> > > * Over the ipc we need a run-this-program-only-once-system
> > This can be very simply achieved using X11 features. Maybe you could
> have
> > a look at
> > http://linux.companionlink.com/cpsutillib.htm
> > and expecially the xsingleinstance utility
> Ahh.. that sounds great also. As long as it's a library that the
> applications can link to and not a separate program, I'm all for it.
> The reason I don't want to use a separate program is because programs
> will be started in many different ways (from menus, start-application,
> other applications, commandline,....) and all will not remember to use
> the xsingleinstance-command.
It is a command, sorry ;)
The problem you mention with it is IMHO only valid for other applications
that want to start another application which is IMHO not necessary. The
only application that starts others is the application manager application
and mabye an extra menu application (which could also be the application
manager just with a menu-tree view).
Or do I miss something here?

> http://www.syncml.org/
> basically all future (and some present) phones and handhelds from nokia,
> ericsson, motorold, ibm, panasonic, symbian and others will use syncml.
> If we use syncml it would mean that we can sync to any application that
> supports those other devices. .. Well.. theoretically anyway.
This is VERY important and your hint will for sure be very valuable!
Me for exmaple did not yet know of this standard ;)
Thanks!

> > > * Some way to be notified if a file is changed (using FAM for
> example).
> > > This would allow us to have the same cool active-sync as ms'
> activesync.
> > Also sounds interesting but I don't know it either. Link?
>
> http://oss.sgi.com/projects/fam/
>
> It would allow us to know exactly when a file has changed and with that
> information we can easily do real time sync.

Hmm ... maybe this can be handy. Do you think this is something we should
consider right from the start or could we keep this as possible feature
for the furture?
The reason I ask is that I have the fear of getting too much needed
fcuntionality into the project right from the start. If make it too
complex before we even have a starting point we might end up like many
projects: Good start but never reach even a first beta release...

> > From my understanding of XML I see the following problems:
> > - XML is completely ASCII based and thus there is a lot of redundancy
> for
> > the many repeating tags in the stored data.
>
> True, but I don't think that is a problem. There is no problem for qpe.
Just because they use it does not make it any better ;)
Only possible solution would be to perform a comaring test. Take a XML
structure, add some hundred records in this way and do the same with a
comparable database. I would suspect even when you GZIP the XML text you
will end up a lot bigger.
Just my guess, we will have to test this.

> > - XML is just the meta format, i.e. any application could use it's own
> > tags to describe it's objects. This could make it very difficult for
> them
> > to interact.
> True, but it's real easy to just look at the format, guess how it works
> and use it. I've created programs to export data from evolution and put
> them into qpe and that all worked very easy thanks to the fact that they
> use XML.
No doubt about it, XML is for sure a very important format.
But as I write in another posting I think we should destinguish between
several formats. XML is for sure good as export format to communicate with
others. But for storage and work I still think a SQL engine is much
easier.

> Also, I really belive that programs should interact over ipc and not by
> writing to files (it might be good sometimes but not a whole lot).
That's for sure true!
Communication via files is technology of the past and not for us!
With Linux we are in the lucky position to have the biggest choice
possible (too big to make the choice easy ;)

> That might be true. I just think that as a developer I would prefer to
> use XML over SQL (I've worked alot in both, and they both have their
> uses, but I think sql is overkill for this).
Pleas don't think of SQL in terms of a bloated SQL server running on the
poor device. It shall just be the API, like it is done by SQLite.
Creating, maintaining and using such a database is just a few lines of
code for an application. I doubt that parsing XML structures is easier or
more efficient.

> > Anyway, very good thoughts and we should keep on discussing those
> issues!
> > Nobody said it would be easy ;) It's a new road we are starting to
> walk
> > upon and only the future will tell where it will go...
> I like that attitude. I think it's very important to make this into a
Thanks ;) That's IMHO the only way those things can work...

> community effort. Looking in the HH-wiki and following some links from
> it you'll see that there are many people that have been trying to start
> a project like this but I think they have failed because they didn't
> make it a community effort.
If I would have the time to do it myself this would have been a possible
threat. But "luckily" I don't have the time ;)

> Another thing I've been thinking about.
> Regarding the window-manager. I totally agree that the windowmanger
> should maximize the windows but we might not want to do that if they are
> dialog-windows. Getting a Yes/No-question in a fullscreen-window seams
> like overkill. Qpe and pocketpc both do dialogs as real windows (that
> are always on top)
The proposal that mallum <breakfast_at_10.am> posted recently takes care of
this.

> /Erik
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--