[jp] start jpilit with --add address X?

Brad Barnett lists at L8R.net
Sat Nov 15 19:54:49 EST 2003

On Sat, 15 Nov 2003 17:26:06 -0500 (EST)
"David A. Desrosiers" <hacker at gnu-designs.com> wrote:

> > What on earth are you talking about?  Do you even program?!
> 	Ever hear of a little project called pilot-link? I've been known
> 	to do a think or two with that project in the past. ;)

Then I am even more mystified by your approach and attitude in the last
few emails.  

> > Nothing has to be reverse-engineered, it's GPL'd.  Reverse engineering
> > is a little more complex than just peeking at open source code.
> 	Except when you have to reverse engineer a completely undocumented
> syncronization protocol (HotSync, which has changed [again] very
> recently), completely undocumented file formats (Palm database
> structures), and device access APIs (independantly-proprietary vendor
> hardware).

You think all this needs to be reverse engineered in order to add a simple
command line option to J-Pilot?  This is the sort of weirdness that made
me question your ability to program!

The problem here is, you've swooped in, told me that adding something to
j-pilot was wrong, then proceeded to tell me a different way to do it,
THEN proceeded to tell me how complex and difficult the new way is. ;)

Come on man, of course I'm not going to agree with you.  Especially when
this "new way" doesn't yet even resolve the simple issue of re-creating
j-pilot's "add contact" dialogue in dozens of mail clients!

You say that there are a variety of different databases that Palm
supports, that one could add an email address to.  Then you tell me that I
need to implement the full GUI layout for all of the fields that can be
added to those databases in Sylpheed?  So, now I have three (and one day
more) contact type databases that Sylpheed needs to know the limits of
various fields for, the options each field supports, the names of all the
fields, and so on?

On top of this, Sylpheed needs to know which type of contact database the
end user is currently using.

However, all of this, every aspect of it, is already known and handled by
J-Pilot.  All that an --add email argument is going to do, is tell J-Pilot
to start, switch to address/contact mode, and insert the email address and
possible first + last name in a new record.

J-Pilot already knows what type of database the end user is using.  It
will already know all the details about that database in the specific.

Frankly, I can't see anything _less_ complex than the method I suggested,
allowing for the needs I list above (and did in my first email).

> > How is this incredibly complex?  You are, seemingly purposefully,
> > trying to greatly exaggerate the complexity of approximately 20 lines
> > of code.
> 	"seemingly"? Odd. I don't "seemingly" try to make things more
> complex, 

So, you are saying you do try to make things more complex?  "Seemingly"
would indicate that this isn't the case.  In other words, that I do not
think you are purposefully doing this, but from my external viewpoint it
appears this way.

Above, I articulate my confusion.  I did not insult you in any way, I
merely informed you that your actions seemed contrary to what I perceived
as your intent to help.

> and in fact, this whole thread, I've been trying to do exactly
> the opposite, remove the complexity, and simplify the process, through
> less(complex) code, less customized one-off functions, etc.

The problem is, it is very doubtful that anything will be more simplistic
than adding a simple argument to J-Pilot.  Why have dozens upon
dozens of mail clients write an entire dialogue that incorporates the
whole J-Pilot "add contact" page.  That is code duplication in the very
worst way.

Secondly, why write a completely separate application that duplicates
J-Pilot's add contact page?  The entire premise of the additions I want to
add is that they allow full and complete control over adding a contact to
the database.

I see this very simple feature in J-Pilot taking approximately 20 lines of
code.  I see it taking about 200 or more if separate.  If implemented in
each mail client, then I see 200 lines of code implemented dozens of
times, causing bloat in each and every mail client.

Again, I don't see this your methods as simplification.  I see it as
unnecessarily code duplication.

> > Really?  You don't think J-Pilot should handle possible corruption
> > issues due to multiple apps or j-pilot occurances accessing the palm
> > databases?
> 	When taken out of context, and contorted to suit your issue, yes,
> 	I suppose it does.

It does what?  Do you mean you agree or disagree with my statement?  You
seem to have misquoted above.

However, as far as I can see, I have taken nothing out of context here.
Below is a snippet of this conversation, restored.  Please keep in mind
that you've been using a very minimized form of quotation, so anything
"out of context" was generally not my fault or intent here.

>>>> 	You might also need to do some extra checking for the existance of
>>>> records in .pc3 not yet sync'd to the Palm, whether or not an active
>>>> J-Pilot process is running at the time, and so on, to avoid record
>>>> collisions.
>>> All of which J-Pilot should (or probably will) handle one day.
>> Ugh, I hope not. 
> Really?  You don't think J-Pilot should handle possible corruption
> issues due to multiple apps or j-pilot occurances accessing the palm
> databases?
> That's what you just said "I hope not" to!
>> Having to call J-Pilot (a gui app) from a non-GUI
>> location, or a headless machine, or a machine without X, or a remote
>> machine for which X11 is not forwarded, is a hassle. Doing it with a
>> non-GUI tool would of course, be ideal, and one that can be used
>> *WITHOUT* J-Pilot in the mix is also a plus. The Unix philosophy would
>> work well here; Lots of little tools that do one job well.
>> 	Heck, Windows doesn't even do what you're asking to do here, and
>> they openly advertise having every feature under the sun.

> 	However, I was stating my dislike for J-Pilot handling the locking
> for other third-party applications accessing the J-Pilot data. That
> isn't the place where this belongs, since in this case, J-Pilot isn't
> even involved in the process whatsoever.

As far as I see it, you did indeed say "I hope not" to what I stated. 
You've been the one trimming out large swaths of text, not me, yet you
claim I'm somehow quoting you out of context?!

You seem to indicate that you do not want J-Pilot to take care of this,
but that you would prefer an external program to handle this sort of
issue.  Fine, well enough, but I'd still like to see this sort of thing
handled in j-pilot _as well_.  Why?  

Well, without J-Pilot having some sort of idea what other J-Pilot
processes are doing, the end user will have quite an issue when it comes
to working with more than one process.  Who's fault is that, for running
two j-pilots?  The end user's, of course, but perhaps j-pilot should only
allow once instance per user?

Something like this would easily resolve any corruption issues that are
caused by my plan to add a command line switch to add a contact to

> > So don't do it.  Who asked you to?  Why does adding a few lines of
> > code mean you have to use j-pilot for everything?
> 	Thank you for slowly proving my point. Let's just restate that
> again, shall we?
> 	"Why does adding a few lines of code mean you have to use j-pilot
> 	 for everything?"
> 	Why do you have to use J-Pilot to write to data that J-Pilot
> 	reads, in this case, from Sylpheed? Why not add the
> 	functionality to Sylpheed, as a plugin (or whatever
>	API Sylpheed supports for that), that just outputs the right
>	records to the $HOME/.jpilot/AddressDB.pdb (and soon perhaps, the
>	ContactsDB.pdb)	file. This is how almost every single Unix 	
>	compatibility application does it. Sylpheed has hooks to J-Pilot
>	already, why not simply add this to that existing base of
>	functionality

I've already answered this above, but I'll state it again.  Writing the
records is not enough.  You need the ENTIRE "ADD CONTACT" dialogue. 
That's everything including all the phone number entries, address, notes,
the lot.

This is what I've been mentioning from the start, and it is a lot of work
to implement all of that in Sylpheed, when J-Pilot has it all.

> 	Again, the choice of how to do this is up to you, or the
> 	developer.
> > I don't see where it does, except in your mind.
> 	Sigh. Thank you, for peering into my mind, over port 25.
> 	Is that the new IPv7 protocol? IP Over Telepathy?

My words above indicate that this is what I believe you think.  I didn't
think I needed to explain this to you, but you seem confused. :/

I'll just cut the rest of this email here.  It's probably best for both of

More information about the Jpilot mailing list