Re: A proposal...

[Philip Streck <scooby captnscooby org>]

At Wednesday, 17 April 2002, you wrote:

>> I would then like to see a new project that would focus on a
>> device-independent conduit framework, and expanding the current 
features
>> of gnome-pilot to be more robust, prettier, etc.
>
>	I've been thinking about these and similar issues for several years
>now, with the advent of non-Palm PDAs running Linux and other operating
>systems. There's quite a few things missing first:
>
>	- Documented file and data formats. Certainly you won't get these
>	  from the Microsoft folks, so you can count those file formats out.
>	  If you decide to reverse-engineer them, you'll always be chasing
>	  your tail.
>
>	- Standards across platforms. How is the data on your Compaq iPAQ
>	  stored? How is it stored on the desktop? How does it get *TO* the
>	  desktop (there's still no sync path from non-PalmOS-based PDA to
>	  *ANY* Linux desktop, other than rsync and similar applications)
>

I'm not proposing that we develop a sync backend to every device 
out there.  What I am proposing is the framework to make it possible 
for someone to use exisiting conduits from this new project to write 
their own backend be it for a psion, pocket pc, or anything else.
By making a framework that is device independent we set are selves 
up for all sorts of cool things in the future.  Think about syncing 
your evolution databases from your laptop to your desktop to your 
pda to your cell phone all at once via bluetooth.  This kind of thing 
would be possible with plugable modules for each hardware device 
that have there own mini conduits on what to do with the data.   


>	Right now, gnome-pilot relies on some of the functions in
>pilot-link. To adapt what exists today to handle a new device would
>(currently) require changes to be made in pilot-link, or the required 
code
>in pilot-link to be copied into a section of gnome-pilot. 

the pilot-link specific stuff would be handelded by the palm os module,
and be extracted from the main framework code.  You wouldn't be 
going directly from the evolution database to the palm database format.
it would have to work in a manner where a middle-man-database format 
was used that both sides recognized.

You'd have to then
>add separate libraries for each device (Palm, Agenda, iPAQ, Zaurus,
Psion,
>Yopy, etc.) and each capability (rom, ram, vfs), and connection 
capability,
>(802.11, Bluetooth, IR, USB, serial, and so on). It's not a small 
project,
>but it could be a worthwhile one in the long run.

Exactly, it would provide us with a great base for future projects.
Luckily the pilot-link folks have done a ton of work with interacting 
with the hardware of the palm so this would obviously be the first 
device module to be developed.

>> Another portion of this new project would be developing a set of core
>> conduits for evolution, gnome-pim?, balsa etc.
>
>	..and adapt all of those for every app that ships on all of those
>devices, 7 address books, 20 calendars, and so on, not including 
proprietary
>applications like ebook readers, browsers, whatever. It's a LOT 
of work.
>

no we dont have to adapt them to all the different formats, by providing 
the base framework we provide the *ability* to easily adapt them 
to another type of device/application in the future.  the conduits 
know nothing about what device they are syncing with.  its kind of 
like a two conduits for each type of application.

>> Eventually when the latter project stablizes we can eliminate
>> gnome-pilot all together.
>
>	How about we all focus on what exists today, fixing what may not be
>working right _today_, and when it's 100% perfect, then talk about 
extending
>it in it's current form (core conduits, Palm based) then extend 
it to other
>non-Palm devices. There's still a lot in gnome-pilot that needs 
immediate
>attention first, before any new features (and the bugs that will 
come with
>them) are added.
>
>	Features are great, but features ALWAYS come after function.
>

I agree 100% with the statement of features after function and gnome-
pilot does need to be ironed out, it's buggy as all heck.  But gnome-
pilot does not provide us with an extensible set of legos to build 
with in the future.

>> I step up to the plate as being a project maintainer/lead for 
this new
>> project but I do not want to pursue this if A) the community doesn't
>> want it, and B) That I will be a lone programmer in this.
>
>	Depending on your need and your own personal timelines, you may have
>to fork what exists today, or send in patches for the existing issues 
to
>speed the fixes and move the project in that direction... but then 
again,
>none of this is our decision, since the maintainer generally has 
the final
>cut on what gets done.
>

I'm not really proposing a fork here, i'm looking at a replacement.
You said it your self gnome-pilot is heavily reliant on pilot-link.


>	In the case of gnome-pilot, they also have to adhere to the
>direction of the GNOME foundation, and the libraries that it relies on.
>

I would like to work directly with the GNOME foundation to make this 
a just another piece in the puzzle that plugs right in.  Think about 
it, a generic conduit that would pull data from gda/gnome-db and 
export it to a generic format that the device/application conduit 
can use how it pleases.. it's an ideal that could be a reality.

>	Just my two beans.
>
>d.
>

and everyones two beans count :)

>_______________________________________________
>gnome-pilot-list mailing list
>gnome-pilot-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-pilot-list
>