I tried PB, loved the idea of java based FireFox plugin, have considered
using the same technique in unrelated application.
But .. disabled PB because
a) got stuck a few times, made my browser slow
b) I'm not yet a big RDF user, so couldn't really capitalize on it yet.
But .. I still like the idea, and was going to setup my own semantic bank
too. I was very interested in the haystack project.. etc
Any, here are my thoughts as a programmer, not a user.
On 21 Jul 2005 at 15:44, Stefano Mazzocchi wrote:
> the rest is
> spent even making I/O worse because lots of bytes are transferred thru
> the localhost socket.
I this a Mac issue? I can't see how localhost loopback socket overhead
would be noticed at all on any platform. It must be related to polling,
looping, select or some other foible.
> 1) decoupling PB from the browser
I think this would make PB quite a bit more useful as a system-wide
service that could be used by other applications.
Like google search runs, so PB/Semantic Bank could be setup to run
locally, and stay swapped out most of the time when it's not in-use.
Another option is using a small tcp-listener application that then launches
the PB backend when it gets a connection, then loops through to PB on
the backend... It can then tell PB to quit if it's idle for a while. I don't see
loopback sockets as being a performance issue considering everything
else that's happening.
Also, this would eliminate JNI, and the browser plug-in component could
use regular http connections to talk to PB.
> - we can think of other plugins that use "piggy-bank" as a local
> service (for example thunderbird plugins that use PB to know which RSS
> feed to subscribe, or that inject email in piggy-bank for facetted
> browsing your email, or your pictures/calendar you name it)
yes!
> CONs:
>
> - installation becomes more painful (and more work for us since we have
> to write different installers for different operating systems) some
> people don't like to have services running (even if things like Google
> Desktop work exactly like this).
Could you just rely on java web-start or something?
>
> 2) find a compression scheme for the URLs.
>
> PROs:
>
> - makes the page a lot smaller (reduces I/O overhead)
>
> - reduces the url-encoding overhead
I am unsure to what this refers to. Do you mean compressing urls used in
RDF?
> - data is saved on disk *only* after regular shutdown. In case of
> system collapse there is data loss. (Jeen, is there a workaround for
> this problem? like saving the new RDF right away before returning)
That would be very bad. I've dealt with applications that, for example,
don't save their preferences until the application "exits normally".
It's confounding when the app dies, or Windows Shutdown occurs (which
apparently isn't a normal exit for this particular application).
I think you really need to write the stuff to disk when you get it.
--
Brad Clements, bkc_at_murkworks.com (315)268-1000
http://www.murkworks.com
AOL-IM or SKYPE: BKClements
Received on Thu Jul 21 2005 - 21:03:56 EDT