[mnet-devel] What's left to be done for 0.7

[Zooko O'Whielacronx]

some specific responses to icepick's ideas:

> For a new release to be equal in function with the old 0.6 release we 
> need two things we don't have in HEAD yet:

Should v0.7.0-STABLE be required to have almost all of the features that 
v0.6 had?  I'm +0 on that question.

At the same time, I advocate that we release v0.7.0.14-UNSTABLE as soon as it 
does anything.  (Which is actually RIGHT NOW!  But I don't want to do the 
package building work right now.  Does someone else want to do it?)


> 1) searching
> 
> Two options here:
>   - Implement the recordkeeper spec (where I would spend my time)
>   - Get the old content tracker working with new mnet uri's (I will not 
> do, but others are welcome to take this up).  If you do this the client 
> and server should use "content tracker v3" messages so as not to confuse 
> any 0.6.2 brokers.

There are open issues in recordkeeper, so it would obviously take longer to 
finish designing and implementing.  On the other hand, in ent world there is 
no central metatracker (or set of metatrackers) to ask "list content 
trackers", so there is an open question about how you would meet content 
trackers.

Now that I think about that, I would be happy to depend on "the BitTorrent 
style search UI" (websites containing mnetURI's) for v0.7.0-STABLE.  +1, but 
I won't try to force it if you disagree.


> wxgui working in mnet_new.  wxgui will 
> run as a seprate process, using twisted to handle network ops.  It will 
> communicate via xmlrpc (for easy of other hackers making use of Mnet) OR 
> twisted pb (for the lower overhead (parsing, bandwidth (important if you 
> are controling your Mnet Node over a modem!)).
...
> The API expressed should follow the CP2PC spec as much as possible.
...
> I'm really looking forward to hacking the GUI again.

Sweet!  I'm really looking forward to you hacking the GUI again, too.  ;-)


>   * Should we stop and convert over to Twisted?

Moving into a new house is a lot of work, even if you optimize by leaving a 
bunch of your stuff sitting around in the old house.

But it sure is nice to be in a comfy new house.

I think I'll write a separate message about this issue.


> Two other ideas I had that someone might want to take up:

TWO ideas?
 
> 1) metadata blocks that forward you on to the real index block

Isn't that part of record keeper?

> 2) Small files in 1 block only.

This is part of the ZNFF spec, but isn't currently implemented.  That reminds 
me that there is another unimplemented twist to that spec: appending an HMAC 
to the inode data to guarantee integrity.

> 3) ZNFFFileStore - index the blocks that make up a file in the file 
> system and then share them as if they were in a normal blockstore.

I don't think this works because of the routing scheme -- you might have a 
block on your hard drive, but nobody is going to ask you for it because you 
aren't the closest node to the block Id.  Am I missing something?

> 4) The Mnet backend should be installed on W32 as a service.
> 
> 5) UPnP NAT traversal into EGTP layer.  I have code that does 99% of 
> what we need for this.

This is redundant with my plan to make ent route around firewalls.  Not to say 
that you shouldn't do it, though.  You can surely do this sooner than I can do 
that, so maybe we should push the 'ent routes around firewalls' feature onto a 
future stable release e.g. v0.7.1-STABLE.

Regards,

Zooko



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel