Sadly, Firefox 3 is now 5 major versions back.

To second Michael, you are *absolutely* welcome to help develop Trean. 
If you have questions on Horde stuff, please feel free to ask on the 
dev list (dev@lists.horde.org - http://horde.org/mail/).

http://bugs.horde.org/ticket/6868
Help is always welcome.  Trean needs some pretty major refactoring 
related to the Horde_Share system to either move it to the new native 
hierarchical sql share driver or to flatten the data storage and 
maintain single level "buckets" of bookmarks that contain tagged 
bookmarks which can be browsed in a hierarchical fashion (similar to 
Ansel's tag browsing feature). This still needs to be discussed some 
more, but IMO, this work should be done before anything else is added 
to Trean.



If your familiar with Horde_Share api (or want to *become* familiar 
with it ;) feel free to dig in, submit patches, ask questions on the 
mailing lists etc...  I was planning on doing this work, but as 
always, there is never enough time for everything :)

Mozilla seems to develop a centralized Browser-Data-System for Firefox 3.



It is still in alpha stdium but i use it and it works great. It syncs 
Bookmarks, History, Tabs, Passwords etc (configurable) on a 
WebDAV-server of your choice. Actual the alpha can save the stuff only 
encrpyted, but there seems to be a unencrypted option planned. Also a 
Documentation of the cryptin-API is available, so trean could adept 
it....



http://wiki.mozilla.org/Labs/Weave



There is a ServerAPI available, but it will change often due to alpha-stadium.

Actually readOnly-Querys about bokmark-data is possible.



Maybe it is a good start to adapt Treans Datastructure (incl. 
possibility to edit) to the needs of FF3 ( does Trean contains 
bookmark-tagging already? ).



Next steps would be the sync-algorith and the encryption...



It woul be nice if i could help to develop trean...



best regards, Torben Dannhauer

probably not worth doing this for ff2 at this point...

http://developer.mozilla.org/en/docs/Places:Migration_Guide

http://developer.mozilla.org/en/docs/Firefox_3_for_developers

Sorry to hear that! Maybe you'll be able to contribute again some day...

Unfortunately I'm just not going to have any more time to finish this. 
  I won't even be around to get the bounty, so I guess if someone 
builds on my solution and finishes it, they can have the bounty.



I hate to leave half-working code behind, but as I understand it 
Firefox 3 will be coming soon and is overhauling the Bookmarks code 
anyways.  My techniques might not even work there.



I assigned the copyright over to Horde, so it's all yours!  Good luck 
with the project.



-- Joey Hewitt

The json-rpc driver is now in CVS, fyi.

I realized these sound like symptoms of some errors going on, which 
aren't reported right now.  Hopefully I can add reporting within a few 
days.  Your other points about status, etc., were still good, though.

Unless we modify jsonrpc to use sessions instead of HTTP auth, that 
won't work.
Right. This is a pretty good explanation:

http://en.wikipedia.org/wiki/Cross-site_request_forgery
As long as it's not something that is passed when the browser makes a 
regular page request, or an xhr request, it'll work.
XHR is protected by cross-domain restrictions; you can do GET requests 
for javascript, but jsonrpc (and the other RPC stuff) uses POST.



Other RPC types could be vulnerable if they could be faked by a form 
submission. I think you're right that a regular form submit couldn't 
be used for jsonrpc (or most of the other RPC types) because you can't 
create that data with a regular form. Since the only other way to get 
the user's browser to do a POST is with XHR, and that's out of domain, 
then I think we're okay here without additional changes and tokens. 
But it's a good thing to think through. :)



I want to sit on this another day or so before committing it, though, 
just in case.



Thanks!

I remembered that the browser is caching the HTTP Basic credentials, 
which is bad.  I think I can prevent that.  I'm hoping after the first 
call using Basic auth, the cookie I get will be enough.



But I think I see now how it's exploitable.  Couldn't someone 
automatically submit a FORM with a POST to Horde, and the auth cookie 
would attach to the request regardless of the domain of the POSTing 
site?  I guess they may not be able to do much with the response, but 
just sending is enough to do nasty things.



So you're suggesting my extension holds a unique, opaque session key 
(probably in addition to the cookie I already have) that isn't stored 
anywhere in the browser proper?



Also, is this really specific to JSON-RPC, or is it something that 
could be a problem with any of the RPC methods?  Because on second 
thought, I think JSON-RPC requests would be difficult to forge because 
XHR is probably protected enough, and they can't be done by FORM that 
I know of, because they aren't sent using the standard URL encoding 
form.  They use a POST Content-Type of 'application/json' or 
something, and the body is straight JSON, not wrapped in URL 
&key=value form.



I hope it makes sense what I'm getting at here!

Thanks for your feedback, and for pointing this out!

I'm sure you know more about this than I do.  But I'm not sure how 
it's exploitable.  How is the extension being "logged in" any 
different from the user being logged in to Horde?  Doesn't 
cross-domain security already prevent a malicious site from doing 
this, whether the user himself is logged in or the extension is?  I 
suppose code not subject to XHR security checks (another extension) 
could make a POST, but such code has so much control already that it 
seems futile to try to protect against it.



Regardless, you bring up some very good points.  We'll want to think 
it through several times.
I'll need to learn how this is done, but I'm sure it wouldn't be too 
hard to implement.



Thanks again.

I've committed the Trean part of the changes. I hesitate the commit 
the jsonrpc implementation, though, because of security concerns. I 
don't know if there is going to be an easy way to fix this, but I 
don't think we can roll it out if it's possible to exploit.



Here's the concern: if a user is using TreanMarks and is 
authenticated, another website with malicious javascript code could 
use XmlHttpRequest to POST jsonrpc requests to Horde without the user 
knowing. This actually goes beyond Trean since the user's 
authentication to Horde would be used; any API method would be callable.



My first thought of how to handle this is that instead of using HTTP 
basic authentication, we need to have the jsonrpc backend use a real 
session, with a session key stored in the extension and included in 
requests as a POST parameter (like the Horde_Form token usage for CSRF 
protection) for checking.



Thoughts?

I think it must be a cached password problem - I just tried on a 
computer where I had had a previous TreanMarks version installed (and 
thus had the password cached) and it is working almost perfectly. The 
only other problem I see so far is that there are a few of my Trean 
folders which show up in Firefox as empty. Any suggestions on how to 
trace where the problem is there?



Thanks!

Okay, keeping the ticket clean. :) Thanks.
Any suggestions on how best to check this? I could commit what I have 
so you can check it out; that might be best.
I was testing at home on my LAN also. Didn't seem to load anything. 
I'll try again today from another computer.
Also in the way of preliminary feedback, with TreanMarks enabled I 
seemed to have some trouble with regular bookmark management - when I 
created a new (local) bookmark folder, it was impossible to rename it 
from "New Folder" to the name I wanted - I could go into the 
properties dialog, but my changes were ignored.



Or was it trying to sync that folder to Trean, and failing because of 
the other failures?

Correct.
Hmm, I don't think I've tested without a cached password recently. 
Perhaps there is a bug.  There could also be a problem if you didn't 
apply my server changes correctly.  I might make some changes when I 
look into the problem with multiple windows; there could very well be 
some issues, but I don't think they're major.
I'll think about how to do this best.  My test server is on my LAN, 
which means I'm oblivious to the more noticeable delays everyone else 
has.



Thanks for the feedback, however preliminary!

Taking a look at this in between semi-productive late night work. Do I 
understand correctly that the server_changes.zip file can be 
discarded, and that treanmarks.diff replaces it completely?



Seems to be slow, so far, but nothing definitive - I was eventually 
prompted for password; no bookmarks showing up yet. The Trean 
Bookmarks folder only shows up in windows opened after a certain point 
- not sure exactly what that point was.



Could really use some status indicators so I know whether it's given 
up or if it's working. :)

Just to give an update, I'm still hoping to look at this soon, but I 
had a hard drive fail and an otherwise miserable week, so I'm going to 
need to rebuild my laptop first before I can look at this. Hopefully 
someone else can take a peek though, too.

OK, here's a diff against CVS HEAD from last night.



Note that you'll have to ensure that the new 
horde/framework/RPC/RPC/jsonrpc.php file ends up in your PHP include 
path.



Hopefully this is much easier for people to review.  I'm not in a 
hurry to see it committed to CVS, but if it's easier for someone to do 
it now, I guess I'm alright with the new JSON-RPC stuff (small change 
to horde/rpc.php, a new jsonrpc.php file mentioned above, and removal 
of obsoleted trean/json.php) being committed.  But trean/lib/api.php 
needs some documentation, if not reworking, before I'm finished with 
it.  If I decide I no longer need some API methods, do we think anyone 
is using them right now?



Here are some things I have in mind for more work on the extension:

o More error checking and reporting

o Finish implementation of separate TreanMarks/Bookmarks menus

o Downloading the XPI from the Horde server

o Setup wizard, a la Foxmarks, with configuration of Horde server URL 
(with nice preset URL set to the server it was downloaded from, 
perhaps other settings pulled from server too), import of Firefox 
bookmarks.

o Multiple Horde servers/users aggregated into the bookmarks

o Start investigating Firefox 3, as I have a nasty feeling its 
"Places" replacement for bookmarks is a new implementation that could 
be drastically different :-)



Any other suggestions?



-Joey



P.S.  I haven't seen any XHR/Firebug errors with this rewrite, so I 
think that's fixed!

Done. I'm hoping to have a look at the changes over the next few 
evenings. Thanks!

Here's some instructions on how to set this up.  You need these files:

treanmarks[1].xpi

server_changes.zip



Get server_changes.zip, extract it, and follow the instructions in 
changes.txt to place the 3 PHP files inside where they need to be.   
(You'll be overwriting existing Horde files in 2 cases, so I'd suggest 
making backups of them.)



Install the XPI on Firefox.  Open Tools -> Add-ons and point the 
extension to your Horde base URL (i.e. http://www.example.com/horde)



I highly recommend making backups of both your Trean bookmarks and 
your local Firefox bookmarks!  Firefox bookmarks are found in your 
profile directory, with the name bookmarks.html



Again, I'm hoping I remembered all changes necessary.  Please make a 
comment if you're having problems!



-Joey



P.S. Will someone with perms delete these attachments, so it's not so 
cluttered:



treanmarks.xpi

treanmarks.diff

emblem-favorite.png

json.php

OK, here's the latest!  It's hard to think of all that's changed since 
last version, since it's a different design.  But, I've got complete 
integration into the browser, including: adding/removing bookmarks, 
organizing them (even custom sorting, though that can't be saved to 
the server), moving them between your local bookmarks and Trean, 
searching them in the Bookmarks Manager.  Syncing should be working 
both ways now.  Bookmarks are saved so that the next time you open the 
browser, it will sync rather than re-download.  (Also you should be 
able to view them offline.)



On the downsides, error-reporting is minimal for the moment.  I think 
the RPC APIs are a bit messy and might need re-thinking.  The options 
to swap bookmark-making command keys, and to put Trean bookmarks and 
local Bookmarks in separate menus are not implemented right now.



As to horde (at) olen (dot) net's question about the special search 
keyword bookmarks, I think this can be done.  It would need a bit of 
hackiness to store in Trean properly, but I think it could be as 
simple as a special "keyword=string" pattern in the Trean description 
or something.  I'll look closer soon.



Hopefully I'm attaching all the changes necessary on the server-side...

They mean that I can't use the extension, unfortunately, because I use 
firebug for work pretty regularly, and with xhr broken some of my 
current work project doesn't work at all. But I can wait for the new 
datasource stuff, so it's up to you to decide which to work on first. :)
Sounds great!

I've also noticed the Firebug errors (and possibly general XHR 
problems, too, I can't remember.)  Are these problems really 
interfering with anything important, or are they just errors in the 
console?  I'll take some time to fix them if so; otherwise, I'll just 
continue working on the new datasource design.



Speaking of it, it's coming along pretty well.  I've got read-only, 
non-syncing support working right now.  It's neat because right away I 
got some new features, like the "Open in All Tabs" item at the bottom 
of folders menus (I hadn't noticed it, or I would have implemented it 
before)  Also, the Trean Bookmarks are available directly within the 
Bookmarks menu right now, and are visible in the Bookmarks Manager 
(Organize Bookmarks), complete with standard working properties 
dialog.  Hopefully I can get a release out soon!

I can confirm that as well, along with some other xhr stuff.

Yes firebug breaks for me as well

Is anyone else seeing that firebug breaks when this extension is enabled?

A few notes on the XPI after using it a little:



- right now Trean only allows one share per user, so it'd be nice to 
skip the top level (i.e. "Chuck Hagenbuch's Bookmarks") and have the 
next level right in the top level menu. Once we allow more shares, 
maybe we can still do this, but with the share name as "labels" of 
menu sections.



- the configuration dialog doesn't have an OK button (in FF2/MacOS). 
Hitting escape seems to save things okay though.



- Also FF2/Mac, when I navigate to a category in the menu, I see 
Loading ... It doesn't change from that to the actual list, though, 
until I move away from the category and then back to it.

Providing a named menu, just like we would provide named extensions.
But it's the only way I can imagine to have configuration-less 
extensions, instead of having the users to enter urls and stuff. And 
it makes sure that the extension running is compatible with the 
installed Horde version, think a few releases ahead.

How does that work when the extension provides a menu? Seems unwieldy 
to me, and likely to cause internal conflicts...

That's what I was talking about. One extension per server.

Any plans to have multiply server support?

No worries, I was talking about the IMP extension I'm working on. ;-)

OK, before you do anything drastic there - I've been playing with a 
new design.  Yes, I keep rewriting lots of things, but I guess that's 
what happens to hobbyists.  I've enjoyed learning everything I have, 
anyways. ;-)  I originally wanted to extend the browser's bookmarks 
datasource to aggregate in the Trean bookmarks.  I gave up on that 
pretty quickly because it seemed too complex.



Then lately I was polishing the extension, and I got tired of all the 
functionality (especially user-interface) I was duplicating.  I've 
gotten through some initial learning-curve problems I had with the 
datasource before, so now I'm experimenting with it.  If I do it 
right, I can transparently and automatically get all the functionality 
normal bookmarks have.  This would be very elegant, powerful, and 
ultimately easy (I hope!)  And unless Mozilla makes any big changes in 
future versions, it would "fit" better (UI-wise) and be more likely to 
work without changes, in newer versions of the browser.
extension.php looks nice.  It will be cool to see Trean serve up its 
own extension.

These are good ideas!

Yes, but I started cleaning up the whole extension which is obviously 
more work than just getting the XPI working.



But the layout I use is the following: imp/extension.php is providing 
the XPI and the XPI is built from files in imp/templates/extension/. 
The layout in this directory is the same like in the XPI to ease 
maintenance. But it doesn't have to. I attach an extensions.php the 
simply takes the directory one-to-one, in real life we need some 
processing, i.e. adding the correct URLs, etc.



This is why I don't agree with your approach of having the 
extension(s) in a separate module or even on the mozilla site. The 
idea is to have one extension per (Horde) site. 1) because users don't 
have to configure any site settings like URLs etc., 2) users can have 
separate extensions for each Horde site, and 3) users can get 
extension updates automatically from the Horde sites, depending on the 
IMP/Trean version they run. With "Horde sites" I obviously don't mean 
horde.org, but sites that have Horde installed.

Alright, so I basically knew what to expect, but damn that's cool. 
I've committed the patches and the XPI works for me with FF2 (tested 
in Parallels on windows).



Minor stuff:

- Do we need to have the popup stuff in Trean for this? I don't see 
obvious places where the extension uses it (might be because I was 
already logged in to Horde when I clicked "Organize"? But I think it's 
fine to have a full Horde UI for that)



- The configure dialog could use a little text wrapping



- I take it this doesn't work with FF 1.5? I got a very odd result 
trying it with 1.5. Not a huge deal, just curious if it's known.



- What would you think about naming it "Trean Places" instead of 
"TreanMarks"? This occurs to me since the bookmarks feature is being 
renamed "places" in FF3.



- The extension icon looks pretty, huh? ;)



Finally, most important: where/how do we want to host and distribute 
the XPI? I assume that we should have the uncompressed files checked 
in to CVS as a TreanPlaces project or something (maybe we should have 
a BrowserPlugins module to hold other stuff, too?); then I guess it'd 
be great to put it up on the moz plugins site if we can get it 
approved. Other thoughts here? Jan, any progress serving the XPI out 
of Horde?



I'm installing this at work tomorrow. Very sweet. Thanks!

It might break the specs indeed, but take a look at how it is 
implemented with IMP/prototype. In imp/lib/IMP.php, 
IMP::sendHTTPResponse(), the json code is encapsulated in "/*-secure- 
*/".

prototype (horde/js/src/prototype.js) automatically filters the 
comments out, see Prototype.JSONFilter and String.unfilterJSON().

It does work with the normal bookmarks.  My question was mainly if it 
was possible to add this kind of functionality to an extension such as 
this.

If so, I can throw away all the local bookmarks in the browser, and 
only use Trean and TreanMarks.

That sounds useful, but what does it have to do with Trean or Horde?

One issue, tough I am not sure it belongs in this Bug#



I have a lot of "QuickSearches" - IE 
http://www.php.net/manual-lookup.php?pattern=%s and such (mapped to 
the keyword "php" so i type "php string" in the address bar and is 
directly taken to 
"http://www.php.net/manual-lookup.php?pattern=string").



Would it be possible to add this to the extension, or should I keep 
that as a separate issue?

Perfect!



Now it works as it should, I believe.

Even with https.



Thanks a lot for your work!

I must not have privileges to remove treanmarks2.xpi.  Will someone do 
so?  I will upload as treanmarks.xpi from now on.



Thanks,

Joey

I'm attaching an XPI that should fix this.  Thanks a lot for the 
detailed report! - I might not have figured it out otherwise.  Read on 
for technical details and request for comments.



Hardcoding is a bad idea!  I've had an assumption in my code for ages, 
and I forgot about it.  For simplicity, I hacked in that the root 
folder would always have ID 1.  This works great for testing, but if 
you have more than one Trean user on the server, I guess it's likely 
to break.



I think this is what has been happening to you.  I'm attaching a new 
XPI with this assumption removed from my code.  It changes the way the 
menu appears.  I see now only one folder at the top level, with 
"joey's Bookmarks."  (I believe this is called a share.)  Everything 
that used to appear at the top level is under that.



I don't have time today, but within this week I'd like to work on more 
advanced caching and prefetching, during the course of which I'd like 
to offer the ability to remove this extra top-level.  It looks like 
other users can share their bookmarks with you, so it may be useful to 
let the user pick which "share" to make the top-level.  Other users' 
bookmarks would then appear as a "John's Bookmarks" folder.  Anyone 
have more suggestions on how to handle the top-level folders (or 
shares)?



I hope this works for you; it's a shame something so silly on my part 
has been holding you up from trying it out. :-)

I still can't get this to work - now I have even disabled https, to be 
able to debug a bit more.

There seems to be a problem with the request TreanMarks is sending, 
that json.php does not understand:



GET /trean/json.php??method=syncBookmarks&params=%5B1%2C%5B%5D%5D



This results in an

(...)

Content-Type: text/javascript

while(1);/*Not found.*/false



The "params" unescaped seems to be "[1,[]]" - not sure what they 
should be or if this is in fact correct but something in my horde 
installation is missing.

OK, can you think of a way I can transparently implement security?  I 
only know of putting something at the beginning of the JSON, so that 
we can strip it off but nobody else can because they can't read it 
directly.  Unfortunately, I'm guessing this will break the JSON-RPC 
spec.

OK, thanks!

No, POSTs can be forged as well.
Exactly. And I actually started working on this yesterday, maybe I can 
show something in the next few days.

Yeah, on second glance it's alright.  I think I've finished 
implementing the backend, but I haven't tested with a real JSON-RPC 
client yet.  I'll probably adapt an existing JSON-RPC library to use 
Horde's AJAX/JSON stuff, and use that for my extension.



As for security, I think the point is moot, now that the only way 
anything useful can be retrieved is with a POST, and nobody should be 
able to forge and read with POST, right?

Well, actually, I don't have to re-compress for my own development 
because there's a way to point Firefox at a directory and it works 
just like an XPI had been installed there.  But if I understand what 
you're saying, it would be neat.  The XPI could be downloaded from the 
Horde server, which would allow us to throw in some subtle features 
like making the XPI's default server URL be the server you're 
downloading from.  (Perhaps that would not be desirable, though.)  Is 
that what you meant?

The spec looks good.
In my head. But it shouldn't be too hard. We have the Horde_Compress 
library that we already use to create ZIP files on the fly. We should 
probably put the XPI contents under trean/lib/XPI or 
trean/templates/xpi with the same layout like in the XPI file, for 
better maintainability.
Congrats! Good for us, I guess.

It would.  I had a reason for deciding against implementing JSON-RPC 
(pretty much the only RPC-over-JSON standard I saw.)   
(http://json-rpc.org/wiki/specification)  Now I'm not sure why, but I 
think it may be that the newest version is still being written up in 
specification.  I'll look at it some more.

Thanks, I'll try that.

This sounds like a good idea to look into.  Where is the source?



Thanks,

Joey



P.S.  Today was my last day of high school, woohoo!  And I'll even 
have a week that will be pretty open for working on this ;)

Several thoughts:
If you still rely on the external API methods defined for Trean 
instead of calling the Trean API directly in json.php, would it make 
more sense to add a generic JSON backend to Horde's RPC library?
It's only an issue for reading the bookmarks, right? A 
Horde::compressOutput() in json.php should probably do that trick then.
Should be.



Regarding the AJAX and JSON stuff inside the XPI, I suggest that you 
use prototype that we use anywhere else in Horde. The most recent 
version has support for a CSRF protection built in.

Heck, we could even build the XPI on the fly including the source 
files directly. Much easier than rebuilding the XPI anytime you change 
something. I plan to do this for IMP since ages.

And here's the XPI.

OK, I finally got some time to play.



I reproduced and fixed a Linux problem.  (Technically, it was on 
Iceweasel, which is the GPL'ified version of Firefox.)  It was causing 
the TreanMarks menu to have only the fixed items (none of the 
bookmarks.)  I'm not sure if it was what others were seeing though.



I also switched to JSON.  I basically just made an interface to the 
RPC calls I already wrote.  The change wasn't quite as "drop-in" 
simple as I would have liked, but I've gotten rid of another layer of 
translation that used to be there for XML-RPC.  I'm kind of hoping :-) 
that the MacOS bug was caused by using XML-RPC, which was implemented 
by a built-in Firefox XPCOM component.  Perhaps it was a little 
different than Windows on the COM side...



I'm still not sure whether JSON is the best way to go, but I'm happy 
for the moment because it cleaned up the code and may be more 
efficient.  At the moment slightly more bytes go over the wires 
because XML-RPC was gzip-compressed, but I don't know how to do that 
for my JSON code.  Anyone know how to do it?



I'd also appreciate some assurance that I got JSON security right.  I 
understand a comment or "while(1);" at the beginning is enough to stop 
people from being able to XSS your data.



A few minor tweaks have been done, like adding the configuration menu item.



Enjoy.  Hopefully I can get to implementing some of the features I've 
planned, while you're testing this.  I'm attaching a new XPI and a 
json.php file to drop into horde/trean/  It requires my previous patch.

Yes, Atom has a publication mechanism - we'd need to implement it, but 
that'd be nice anyway. :) I think JSON is probably the way to go for 
now for simplicity on both the Trean and Mozilla sides, but that if 
Atom is easy to deal with on the Mozilla side we could move to that 
easily, and perhaps sooner rather than later.
Synchronization protocols are a tricky problem. We support SyncML in 
other parts of Horde, and that'd be very complete, but we'd need a 
full SyncML client in Mozilla, and that'd be a ton of work. I think a 
relatively primitive mechanism is fine for now - especially if 
creating/editing bookmarks are delegated to Trean.
You're probably right.
Ah, nice.
Should be, they were related to the popup windows and such.
Cool, looking forward to it.

I tried it unsuccessfully on Linux FF 2.0.0.3.

But sync now don't even prompt for the username/password for the RPC calls.

I hope something didn't permanently break for you. :/  I have no idea 
where that came from, either.  I see where it gets logged in the 
source, but I don't know why my extension could cause a command line 
flag to be passed.  I'll look into it.  It looks like you're using 
Mac.  I have Windows, but it shouldn't matter with 
platform-independent code...
Thanks!  I'll incorporate it next time I update.
Yes, all of the other extensions I've seen make a separate menu.   
(Shame that there's no simple way to make a bookmarks backend.)  But I 
think it would be possible to add the bookmarks onto the main bookmark 
menu, either directly or in a submenu labeled Trean/Horde or whatever. 
  I want to do this, but just haven't yet.
Yeah, I thought about json afterwards.  Perhaps that would be much 
more efficient and simple.  It might also make sense to leverage the 
existing RSS stuff, yeah.  My only problem is wondering if it makes 
sense to have separate download/upload mechanisms.  (Though I think 
RSS or Atom has a publication mechanism as well, which could be used 
for uploading.)  I should also note that the synchronization is pretty 
primitive right now - limited to simply the existence of bookmarks; it 
doesn't sync changes to URL and such.  Perhaps another protocol would 
better address more complete synchronization.  What do you think?
I actually consciously decided against this to cut down on clutter at 
the top of the menu.  But I think you're right that it belongs there.   
:-)
Renaming it sounds fine, but I'm wondering if the menu would become 
too confusing if other features were integrated.
[paste]
It's stored in the Password Manager (Tools -> Options -> Security -> 
Show passwords), with a site of "treanmarksExtension."  I stole the 
idea from another online bookmarks extension. :-)



[paste]
OK.  I hope they're still useful if the bookmark transfer mechanism is 
switched. :-)



I'm fairly busy at the moment, but I'm hoping next week I can work on 
these things more.  In the meantime, I would appreciate peoples' 
comments on RSS/JSON and perhaps the UI issues.

Last note for now - I committed several parts of your patch that made 
sense independently (at least, enough sense).

One other question - the extension seems to have a persistent cache of 
credentials to log in to Horde. How is this handled?

I've been looking in to this with high hopes but unfortunately limited 
success. :)



Seems like now that I have TreanMarks installed and configured, every 
time I launch Firefox, this shows up in my error log:



Error: Warning: unrecognized command line flag -psn_0_9699329



Source File: 
file:///Applications/Firefox.app/Contents/MacOS/components/nsBrowserContentHandler.js

Line: 655





I honestly have no clue where that's coming from, but it's definitely 
related. The TreanMarks menu never gets past "Loading ..."





I'm attaching a 32x32 Trean icon (straight from the Tango icons).





Other comments:



- I'm a bit iffy on the separate menu. But if this is how other 
bookmarks extensions work I guess that's fine. It's certainly easier 
to let the main Bookmarks menu alone.



- For other ways to do it than xmlrpc struts, it depends what you want 
to work with on the browser side. We have the beginnings of RSS/Atom 
feeds for Trean; if this extension could use that data that would 
definitely simplify things. Another possibility is to use json instead 
of xml-rpc; that data could be requested directly from Trean and would 
be much smaller than XML. And could just be eval'd (after stripping a 
necessary security delimiter) on the javascript side.



- Can we have a configuration menu item right in the TreanMarks menu?



- What do you think about calling the menu item "Horde" so that 
perhaps in the future it could host other Horde features? Or should we 
keep things separated into other extensions?



Btw, I'm using FF 2.0 - not sure if versions are an issue here.



I'm excited again about this - hope to get some updates from you soon. Thanks!

OK, I just tested https with both a certificate signed by an Authority 
in Firefox (it happens to be a self-signed cert from me, which I used 
to sign this testing cert), and with a testing "localhost" certificate 
that came with Apache.



The CA-signed one gave no warnings at all and I was able to browse 
Trean in the browser and use the TreanMarks menu.  The testing cert 
gave two warnings: that it was not signed by a trusted authority and 
that the hostname didn't match.  When I accepted it temporarily 
however, both browsing and usnig the TreanMarks menu worked.



I even verified with a packet sniffer that the packets were indeed 
SSL.  I know the error-handling of my plugin could use some 
improvement, so perhaps I'll do that within the next few days and you 
can try again.  If we can't figure anything more out, perhaps some 
exchanging of server URLs and test accounts is in order?



Thanks,

Joey Hewitt

Moving to Feedback until Joey can update the code. Looking forward to 
checking it out then.

Hmm, sorry to hear it doesn't work.  Unfortunately I won't be able to 
take a closer look until next weekend. :-(



I meant to test out https, but never got around to it.  I think you're 
right that it's the cause.  I'll test it out next weekend.

The trean patch applied cleanly, but I can't get the xpi to work properly.

It installed, and i get a new "TreanMarks" menu.  I also set the 
preferences correct, and "add bookmark" works, however, the bookmarks 
are never visible in the TreanMarks menu.

Neither after clicking "sync now" nor after waiting for an automatic 
sync to happen.



Mind you, this horde installation is on an SSL-enabled server, so I 
use https-URLs.

I have not looked at the code, but from previous experiences this can 
lead to problems with javascript/rpc if the certificate is not 
accepted and such.

Just a wild guess.

Ahem. Either I'm crazy and didn't attach, or that attachment didn't 
make it because it was coming over a Samba share! ;)

another attachment



P.S.  Sorry, I haven't written much documentation yet... Configure the 
extension in Tools -> Add-ons.  Find the "TreanMarks" entry and click 
Options button.  From there things will probably be pretty 
self-explanatory.



P.P.S.  I'd love to see localization done! :-)  And it won't be as 
hard as it looks, because a lot of strings are reused from the 
Bookmarks menu.

Here's the first (beta-ish) release of my solution to this bounty.   
I've oh-so-creatively named it TreanMarks (better suggestions 
welcomed.)  It comes in two pieces: a patch to server-side Trean, 
mostly to add RPC calls, and a Firefox extension implemented in 
javascript.



Features

=================

o 100% JS means it should be cross-platform! (or, as much so as 
XmlHttpRequest is)

o A TreanMarks menu next to the Bookmarks menu

o Support for bookmark/folder deletion, adding bookmarks (by 
delegating to Trean itself in a popped-up browser window), and 
bookmark/folder properties (also delegated to Trean)

o Locally caching the bookmarks and then "synchronizing" via RPC, to 
cut down on time spent down-/up-loading



TODOs

=================

o Look into 'compressing' server response XML (for RPC), by not 
indenting prettily. I don't think this is even offered through the PHP 
extension :( But I think it may cut down on wait times considerably.

o Pre-fetching bookmarks on browser load

o Caching bookmarks to disk, for "offline" access (if that makes any 
sense) or just quicker pre-fetches on browser load



Bugs

=================

o Each browser window keeps its cache separately, so that means your 
Trean bookmarks have to be loaded "into" each window.  I'd imagine 
this might be simple to fix, I just haven't got around to it yet.



Request for Comments

=================

I've actually been wondering if there's a different, much better way 
to go about this.  Are there already (preferably HTTP-based) protocols 
to do stuff like this?  Perhaps Atom?  Anyways, I'll get this code out 
there since I've already invested a bunch of time into it. ;)



Files

=================

o treanmarks.diff is a "cvs diff -Nur HEAD" of all my Horde-side changes.

o treanmarks.xpi is a Mozilla extension installer package.  It's a 
renamed ZIP file, so you can get at all my extension source in there. 
(By the way, anyone have a 32x32 Trean "heart" icon?)

Yes, I meant custom sorting.



The "keyword" field seems to accept any string, but it only works if 
it is a single word.

(So you are allowed to type in "foo, bar baz", but then neither word 
will work as a keyword for that bookmark).



For separators I had an idea of implementing them as some kind of 
"special" bookmark.  I believe that would be the easiest to code. It 
would add them to the database just as any other bookmark, but with a 
special name or some other flag to distinguish them from normal 
bookmarks.  That way you would not have to add a lot of special code 
to deal with them.  This  depends on custom sorting ofcourse, as we 
would need that to make the separators show up where we want, and not 
grouped together at the top or bottom of the list...



We could then display them as a simple <hr> or something in the Trean 
interface if we want that at a later stage.

Sorting is implemented now (though I guess you mean custom sorting; 
that's possible too but not done yet); do you happen to know if the 
keyword field in Firefox expects a single keyword, or a 
comma-separated list, or what?



I'm not sure what to do about separators - I don't think it'd make 
sense to display them as part of the main Trean interface, but if it'd 
need to be stored, we can probably do that.

We should first make sure Trean can handle the field "keyword" (this 
is probably quite easy) and maybe include support for "separator" too.



And maybe a way to sort the bookmarks.

Bounty added:

http://horde.org/bounties/details.php#trean_firefox_addon

Write an extension for Mozilla/Firefox to read/write bookmarks 
directly to/from a Horde server.