Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Daniel Chudnov <daniel.chudnov@ya...> - 2000-10-11 18:54:26
Ok, so i'm running opennap (win-0.36 binary, dub.med.yale.edu:8888 if you
want to check in... but go easy, eh? :) and looking at the protocol. I'd
heard that napster was really just an irc hack, and now I see why. I'm at
a severe disadvantage here because I've never really been a regular irc
user, let alone an administrator or hacker.
So with the basic caveat that I'm just looking at napster at this point...
Two basic questions come to mind immediately: first, how exactly is the
protocol, as documented at http://opennap.sourceforge.net/napster.txt ,
related to the IRC specs? How much of the IRC bits really need remain? I
can see how some of the stuff like handling nicks and banning folks might
be useful, but never having done this before it's hard to know whether it
makes sense to just add on a few message types or expand handling of an
Second, what's the best way to handle metadata? I'd guess it would be
fairly simple within the napster context to do a simple replacement of the
filename handling, maybe expanding it in practice to pass OpenURLs
(http://sfx1.exlibris-usa.com/OpenURL/openurl.html) where something like
pid=filename:whatever.ext is used as local-identifier metadata. That way
we could default to the OpenURL semantic definitions for handling books or
articles or whatever. The server would simply need to do the right things
with the fields, and the clients would need to grow to accomodate
specifying genres and fields in searches.
Hmm. Maybe one of the other protocols more specifically handles flexible
metadata and doesn't have any irc bloat (although it's probably not
geek-PC to call it bloat)?