imv-devel Mailing List for Information Meta View (Page 2)
Status: Planning
Brought to you by:
vinodgk
Menu
▾
▴
imv-devel — For developers only!
You can subscribe to this list here.
| 2002 |
Jan
(14) |
Feb
(16) |
Mar
(26) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rushi D. <ru...@vs...> - 2002-03-04 17:29:23
|
The BAD NEWS is that we didn't win any prizes at the project
competition. The GOOD NEWS is that some students found it interesting.
Here's a more detailed report.
There were only two judges for the competition. As per Santosh's
suggestion, we tried to make the presentations brief. However, neither
of the judges were from databases or internet applications background.
The first judge was quite uninterested, even though Pavan tried last
minute attempts to impress him with some of the advanced features of IMV
(i.e. importing data, aggregation, public/private key authentication).
He wanted to see the code which was absurd because there is no starting
point in reading the code (before seeing the system architecture,
reading the javadocs, etc).
The second judge came very late. It was 7:30 pm on Sunday evening. We
were the second last team to be judged and most of the people had left,
leaving the college deserted. He gave us exactly 2 minutes, half of
which was spent in correcting his misunderstanding that our project was
an AI project that could take unstructured information and parse it to
convert into some structured organization. Again since he had no idea
about WebDAV (or probably even HTTP), there wasn't any use going into
the details.
There were no judges today (i.e. Monday) which was unfortunate because
we were prepared to deliver better presentations. We were quite happy
with our presentations to the student visitors (from 2nd and 3rd year),
who liked the project. [Santosh, it was so much better than the one we
gave to Soam Vasani].
We did not get a chance to see other projects at the exhibition. But we
interacted with the two teams whose projects seemed very much related to
the problem that IMV addresses. One of them from D.Y. Patil College were
making a software that could convert data in RDBMS, Flat files, OORDBMS,
etc into XML which could be served over the Internet using SOAP. A
presentation layer then converted this XML into HTML, WML or MS Word
format. One interesting feature was how data went into HTML so that it
was editable through a form which generated a SOAP request back to
update the database. Since our data is already XML, it would be very
easy for them to provide access to IMV data apart from RDBMS and we
could use their method as a mechanism for generating HTML pages/forms
based on some template to make an interface for IMV data.
The second project (which was form AIT) was an MSN Messenger bot (a
pretty simple one) capable of doing three things:
1> Provide web-based services over command line... example google
search, movie tickets, cricket scores, weather, find e-mail address etc.
The funda was to get command line request, fetch info from a website,
strip data from HTML page and send it back to the user.
2> Chat natural language. They didn't invent anything. They were
using Dr. Wallace's AI engine and the data was stored statically in AIML
files. The capabilities were limited.
3> Remote desktop. Over some access control mechanism (which I would
never trust), you could start applications on a remote machine, start
playing files, etc. This wasn't part of the bot, but an extension of MSN
Messenger.
The AIT team had already heard about the IMV server (probably through
Amrit and gang) and we asked them to consider using IMV as a datastore.
Finally, thanks to Santosh for visiting. More help/preparation required
before PICT's Impetus and Concepts.
Later,
Rushi
|
|
From: Rushi D. <ru...@vs...> - 2002-03-02 19:28:05
|
AIT AIT wrote: > We are having trouble with SEARCH, we are unable to use it.We tried > the same format that you have specified in the draft.But we keep on > getting a error response METHOD not defined.(We are using IMV0.20) Please paste the request/response that you are sending in an e-mail. Anyway, I recommed that you dump 0.20 and move to 0.20a (simplified syntax). I have uploaded imv-0.20a which is actually imv-0.21. The search method works perfectly. Also note that the syntax has changed in this version for all methods. Review the examples in the Internet Draft attached. Also the data store files are not compatible so use the one attached in this mail (unjar it to X:\var\jdbm, where X is the drive on which you run tomcat). > Can search be used to do the followings(and how). > > 1. Find out all meta-nodes/relations in a datasource. Nope. There's no MetaNode/MetaRelation discovery mechanism. We assume that the user puts links to each MetaEntity that he wishes his readers to browse/search. If the graph is fully connected, then only one link is necessary. The rest can be navigated. > 2. Find all datanode/relations instances of a given metanode/relations. Yes. Omit the <where> clause. > We are free on tuesday and wednesday (full day) so maybe we should meet. Definitely. Wednesday is our project day. Tuesday morning will also be fine. Choose. Later, Rushi |
|
From: Santosh D. <sa...@us...> - 2002-03-02 06:52:42
|
Hi Rushi, Vivek, <snipped> > Could we postpone the meeting to the middle of next week? > Tuesday (Morning), Wednesday (whole day), Thursday > (Afternoon), Friday(Morning) will be fine. I will be available this entire week, so all that remains is for the AIT group to confirm their availability. > Could someone e-mail me the telephone numbers of the AIT > guys? I will call them up in case this mail doesn't reach > them in time. Vivek, would it be possible to call them up and inform them ? > You are welcome to visit us at the project competition > this weekend. The exhibition is on from 9:30 to 5:30 on > both days. Santosh, this is your alma mattar, so more > reasons to visit. Thanks, but then I also hated the college ;) I will be there ... Cheers, Santosh > Later, > Rushi and Pavan ------- Original Message ------- > From: Rushi Desai <ru...@vs...> > To: "imv...@li..." <imv...@li...> > Subject: [Imv-devel] [IMPORTANT] Can't make it to tomorrow's meeting. > Date: Fri, 01 Mar 2002 22:41:04 +0530 > > > We will not be able to attend the meeting scheduled tomorrow (Saturday > 2nd March, 2002). We are extremely sorry for informing you on such short > notice. We plan to present our project at BVPCoE's inter-collegiate > project contest tomorrow and day after. We decided to take part at the > last minute. Could we postpone the meeting to the middle of next week? > Tuesday (Morning), Wednesday (whole day), Thursday (Afternoon), > Friday(Morning) will be fine. > > Could someone e-mail me the telephone numbers of the AIT guys? I will > call them up in case this mail doesn't reach them in time. > > You are welcome to visit us at the project competition this weekend. The > exhibition is on from 9:30 to 5:30 on both days. Santosh, this is your > alma mattar, so more reasons to visit. > > Later, > Rushi and Pavan > > > > _______________________________________________ > Imv-devel mailing list > Imv...@li... > https://lists.sourceforge.net/lists/listinfo/imv-devel > |
|
From: Rushi D. <ru...@vs...> - 2002-03-01 17:06:20
|
We will not be able to attend the meeting scheduled tomorrow (Saturday 2nd March, 2002). We are extremely sorry for informing you on such short notice. We plan to present our project at BVPCoE's inter-collegiate project contest tomorrow and day after. We decided to take part at the last minute. Could we postpone the meeting to the middle of next week? Tuesday (Morning), Wednesday (whole day), Thursday (Afternoon), Friday(Morning) will be fine. Could someone e-mail me the telephone numbers of the AIT guys? I will call them up in case this mail doesn't reach them in time. You are welcome to visit us at the project competition this weekend. The exhibition is on from 9:30 to 5:30 on both days. Santosh, this is your alma mattar, so more reasons to visit. Later, Rushi and Pavan |
|
From: Santosh D. <sa...@us...> - 2002-03-01 05:50:07
|
Venue: Bhageerath, 5B Conference Hall
(Santosh will book the hall)
Time: Saturday, 2nd March 2002; 2:30pm
Reqd.
Attendees: AIT Project Group,
MIT Project Group # 2.
CC- Amit, Vivek, Santosh
Agenda:
1. UI Requirements & Deliverables.
2. To take stock of UI Progress.
3. Clarify any technical issues from either team.
Thanks,
Santosh
|
|
From: Rushi D. <ru...@vs...> - 2002-02-27 18:26:45
|
I've attached the updated Internet Draft to this e-mail. Apart from additional sections on SEARCH, auth and access control, this draft has also been patched to the non-hierarchial syntax that were introduced in version 0.20a. We are almost certain of incorporating the new, improved and cleaner presentation of XML data of version 0.20a and we might see 0.20a turn into 0.21. I'll try to get it uploaded by Friday. I think this is the first time SEARCH is being documented. Please have a look. Later, Rushi |
|
From: Vivek S. <sv...@ps...> - 2002-02-27 13:14:32
|
Hi santosh, Saturday seems fine with us. We both will be there. Vivek -----Original Message----- From: Santosh Dawara [mailto:sa...@us...] Sent: Wednesday, February 27, 2002 11:11 AM To: ru...@ma...; sv...@pe...; AIT AIT; am...@pe... Cc: imv...@li... Subject: Re: [Imv-devel] Re: Hi all, I hope Vivek and Amit have also joined the Sourceforge Mailing List if not please use the following link - http://sourceforge.net/mail/?group_id=43868 <snip> <summary> User Interface specifications are being thrashed out between the 2 Project Groups. </summary> </snip> > I think we should meet this weekend to discuss the issues > and see the progress/plans. Saturday would be fine (but > I'm not sure if PSPL people will be available). Otherwise > Friday. Saturday will be fine with me, I have added Vivek and Amit to the loop also. They should reply and clarify if they will be attending. Post Lunch say 2-3 pm is fine. Take your pick. Cheers, Santosh |
|
From: Santosh D. <sa...@us...> - 2002-02-27 05:41:27
|
Hi all, I hope Vivek and Amit have also joined the Sourceforge Mailing List if not please use the following link - http://sourceforge.net/mail/?group_id=43868 <snip> <summary> User Interface specifications are being thrashed out between the 2 Project Groups. </summary> </snip> > I think we should meet this weekend to discuss the issues > and see the progress/plans. Saturday would be fine (but > I'm not sure if PSPL people will be available). Otherwise > Friday. Saturday will be fine with me, I have added Vivek and Amit to the loop also. They should reply and clarify if they will be attending. Post Lunch say 2-3 pm is fine. Take your pick. Cheers, Santosh |
|
From: Rushi D. <ru...@vs...> - 2002-02-26 17:18:04
|
AIT AIT wrote:
> 1. Presently the GET method returns a HTML document and there is
> no other way to know the instances of datanodes and relationships of a
> metanode it would be more convenient for us if you modify this method
> so that the response is in XML format. Can this be done ?
The GET method is not *required* to respond to any requests according to
the IMV Internet Draft. We have implemented it for the purpose of
debugging/verfication. To get instances, you will need to use the
SEARCH method that hasn't been documented yet. It returns multistatus
reponses in XML format so you will be able to do what you want to.
> 2. If a URL points to a metanode we will display it in a table
> with heads as the attributes and columns as datanodes(the user may add
> new instances and edit values) ,there will be a separate area for
> relations. If the url is a datanode then will display it in a
> form format.
Sounds good. I suggest you need an interface for editing MetaEntities as
well (adding/removing properties, changing system properties). Here's a
brief list of interfaces required:
a> Creating new MetaNode
b> Creating new MetaRelation
c> Editing MetaEntities (adding/removing MetaAttributes and system
properties)
d> Editing DataEntities (adding/removing DataAttributes and system
properties)
e> Editing Attributes (remember, attributes also have system
properties and will probably require a form that opens from
interface-c/d for finer control)
f> Spreadsheet (MetaEntity x Instances)
> 3. Don't you think it will take a long time to access/update
> information as the number of requests are quite large.
You need to cache changes and flush them on commit. That could reduce
number of requests and improve client performance. For example, you know
that you don't need to send a PROPPATCH for every cell in the
spreadsheet, but only after the entire row is edited (so multiple cells
can be updated). You could cache changes to multiple rows and flush the
PROPPATCHes after say the user presses "SAVE" or "COMMIT". In many
cases, it is likely that the user will make several changes before
actually wanting to commit.
> 4. What is SEARCH for ?
Similar to SQL's "select" query. You can SEARCH within MetaNodes or
MetaRelations for instances that match a criteria. SEARCH uses <select>,
<from> and <where> XML tags in SQL-like syntax. Without a <where>
clause, SEARCHing within a MetaNode will yield all its DataNode
instances. <select> will let you choose what properties you are
interested in. Responses can be limited using the <where> clause to give
an expression (like where LastName='Singh').
SEARCHing within a MetaRelation is similar to searching three tables of
SQL joined for a many-many relationship. You <select> the properties
from the three Entities (srcNode, MetaRelation, destNode), <from> the
MetaRelation and specify filters in the <where>clause. Figure out this
example. I have a Song and User database of people's mp3 repositories.
(Note, there is another paragraph after the following example)
========================================================
>>> Request
SEARCH /imv/pavan HTTP/1.1
Content-Type: text/xml
Content-Length: 700
<searchrequest>
<basicsearch
xmlns:m="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7"
xmlns:msrc="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#src"
xmlns:mdest="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#dest"
>
<select>
<msrc:title/> <!--
This is from 'song' MetaNode -->
<msrc:artist/>
<mdest:username/> <!-- This is
from 'user' MetaNode -->
<m:rating/> <!--
This is from 'availableWith' MetaRelation -->
</select>
<from>
<scope>
<href>379802de-00ec-1000-ab9b-cc1c9f8389c7</href>
<!-- This is the MetaRelation ID -->
</scope>
</from>
<where>
<ge>
<!-- Greater than or equals -->
<prop><m:rating/></prop>
<literal>4</literal>
</ge>
</where>
</basicsearch>
</searchrequest>
>>> Response
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset=utf-8
Date: Sun, 24 Feb 2002 10:20:40 GMT
Transfer-Encoding: chunked
Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector)
1098
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:I="urn:schemas:imv:">
<D:response
xmlns:m="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7"
xmlns:msrc="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#src"
xmlns:mdest="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#dest">
<D:href>http://localhost:8080/imv/pavan/37a0d42d-00ec-1000-a771-cc1c9f8389c7</D:href>
<D:propstat>
<D:prop>
<m:rating>5</m:rating>
<msrc:title>Beautiful day</msrc:title>
<msrc:artist>U2</msrc:artist>
<mdest:username>maverick</mdest:username>
</D:prop>
<D:stat>HTTP/1.1 200 OK</D:stat>
</D:propstat>
</D:response>
<D:response
xmlns:m="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7"
xmlns:msrc="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#src"
xmlns:mdest="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#dest">
<D:href>http://localhost:8080/imv/pavan/37a1f3c7-00ec-1000-919e-cc1c9f8389c7</D:href>
<D:propstat>
<D:prop>
<m:rating>4</m:rating>
<msrc:title>Video</msrc:title>
<msrc:artist>India Arie</msrc:artist>
<mdest:username>Santosh</mdest:username>
</D:prop>
<D:stat>HTTP/1.1 200 OK</D:stat>
</D:propstat>
</D:response>
<D:response
xmlns:m="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7"
xmlns:msrc="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#src"
xmlns:mdest="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#dest">
<D:href>http://localhost:8080/imv/pavan/37a081e2-00ec-1000-c61c-cc1c9f8389c7</D:href>
<D:propstat>
<D:prop>
<m:rating>5</m:rating>
<msrc:title>Beautiful day</msrc:title>
<msrc:artist>U2</msrc:artist>
<mdest:username>hyporg</mdest:username>
</D:prop>
<D:stat>HTTP/1.1 200 OK</D:stat>
</D:propstat>
</D:response>
<D:response
xmlns:m="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7"
xmlns:msrc="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#src"
xmlns:mdest="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#dest">
<D:href>http://localhost:8080/imv/pavan/37a231fc-00ec-1000-c46c-cc1c9f8389c7</D:href>
<D:propstat>
<D:prop>
<m:rating>4</m:rating>
<msrc:title>Video</msrc:title>
<msrc:artist>India Arie</msrc:artist>
<mdest:username>hyporg</mdest:username>
</D:prop>
<D:stat>HTTP/1.1 200 OK</D:stat>
</D:propstat>
</D:response>
<D:response
xmlns:m="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7"
xmlns:msrc="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#src"
xmlns:mdest="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#dest">
<D:href>http://localhost:8080/imv/pavan/37a2ddca-00ec-1000-bc24-cc1c9f8389c7</D:href>
<D:propstat>
<D:prop>
<m:rating>4</m:rating>
<msrc:title>Walk On</msrc:title>
<msrc:artist>U2</msrc:artist>
<mdest:username>maverick</mdest:username>
</D:prop>
<D:stat>HTTP/1.1 200 OK</D:stat>
</D:propstat>
</D:response>
<D:response
xmlns:m="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7"
xmlns:msrc="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#src"
xmlns:mdest="http://localhost:8080/imv/pavan/379802de-00ec-1000-ab9b-cc1c9f8389c7#dest">
<D:href>http://localhost:8080/imv/pavan/37a27356-00ec-1000-cf19-cc1c9f8389c7</D:href>
<D:propstat>
<D:prop>
<m:rating>5</m:rating>
<msrc:title>Video</msrc:title>
<msrc:artist>India Arie</msrc:artist>
<mdest:username>maverick</mdest:username>
</D:prop>
<D:stat>HTTP/1.1 200 OK</D:stat>
</D:propstat>
</D:response>
</D:multistatus>
=======================================================
If you were observant, you would have noticed a slight variation in the
XML presentation of the properties. The two-level hierarchy for
attributes has been removed. That means, instead of:
<prop>
<someattribute>
<value>Some value</value>
</someattribute>
</prop>
The new syntax is simply:
<prop>
<someattribute>Some value</someattribute>
</prop>
This makes things simpler. Both system properties as well as attributes
are at the same level of hierarchy. The system properties of attributes
are available via methods defined on the attribute URLs. We are
following the same sytax for all other methods as well. That will be
available in version 0.20a which I'll upload as soon as I've finished
the tests.
All this will be clearer with the new Internet Draft accompanying
version 0.20a.
I think we should meet this weekend to discuss the issues and see the
progress/plans. Saturday would be fine (but I'm not sure if PSPL people
will be available). Otherwise Friday.
Later,
Rushi
|
|
From: Rushi D. <ru...@vs...> - 2002-02-24 04:44:14
|
Mostly for AIT group: See attachment (Rest are already aware). |
|
From: Santosh D. <sa...@us...> - 2002-02-23 15:00:21
|
Hi, As far as possible stick to the standard signified by http://www.ietf.org/rfc/rfc2518.txt for PROPFIND and search, I Agree with the following - Don't provide the System Properties if not asked for. However, due to the heirarchy the interpretation of this into practice is difficult But definitely avoid making assumptions.(like when providing only the value to a query which requests a propfind on an entity) That behaviour, in my opinion is unwarranted. Instead you might want to look at how to simplify the schema itself, if you feel that the current schema results in redundancy in the reply. Thanks, Santosh > We are using two level hierarchy for showing system > properties of attributes in the PROPFIND/SEARCH > responses. To keep things simple, > reference is only make at the entity's property (i.e. > system prop or attribute). For example, a PROPFIND may > want the attributes... > > <prop> > <firstname/> > <lastname/> > </prop> > > More often than not, only the value of the attribute is > required. But the current implementation provides all the > system properties of the attribute in the response. > > <prop> > <firstname> > <value>Vinod</value> > <type>DataAttribute</type> > <accessRead>45</accessRead> > <timeCreation>25 feb 2002 etc</timeCreation> > blah... blah... blah.. > </firstname> > <lastname> > <value>Kulkarni</value> > <type>DataAttribute</type> > <accessRead>45</accessRead> > <timeCreation>25 feb 2002 etc</timeCreation> > blah... blah... blah.. > </lastname> > </prop> > > In the syntax that we have defined, an IMV-attribute is > depicted as an XML-Element that can contain IMV-Sys-prop > XML-Elements which contain > text. Access to attributes can be made only through the > entity to which they belong. > > But most of the times, during say a search, the user is > only interested in the value. Currently search responses > are polluted with a lot of junk (unrequired) data in > order to maintain the orthogonality of the syntax. > > An alternative could be to use only one-level hierarchy. > So in IMV speak, IMV-attributes would be XML-Elements > containing text directly that constitutes to the value. > > >> Request > > <prop> > <firstname/> > <lastname/> > </prop> > > >> Response > > <prop> > <firstname>Vinod</firstname> > <lastname>Kulkarni</lastname> > </prop> > > If the user is really interested in the attributes > properties, he would have to propfind on the attribute > (i.e. on /imv/mydatasource/00923402-uuid- > 9403290/firstname), which would return: > > <prop> > <value>Vinod</value> > <timeCreation>26 feb 2002..etc</timeCreation> > <accessRead>46</accessRead> > ... > </prop> > > However, in special cases the user will be interested in > the attribute's properties (esp "mandatory" property of > metaAttributes). This could be > solved using... > > <prop> > <firstname mandatory="true"/> > <lastname mandatory="false"/> > </prop> > > So, which XML presentation should be follow? > > Later, > Rushi > > > > _______________________________________________ > Imv-devel mailing list > Imv...@li... > https://lists.sourceforge.net/lists/listinfo/imv-devel > |
|
From: Santosh D. <sa...@us...> - 2002-02-23 13:14:42
|
Hi, This is good work :) Vinod maybe unavailable for the coming week, at this time I would like to review the code & design. During the same period I would like to suggest you continue with the AIT group on the UI and find out what enhancements would be required to the DAV interface to adhere more closely to standards. With the UI in place for Read and Write the next few phases of development will be way quicker. Cheers, Santosh ------- Original Message ------- > From: Rushi Desai <ru...@vs...> > To: "imv...@li..." <imv...@li...> > Subject: [Imv-devel] Version 0.20 is out! > Date: Fri, 22 Feb 2002 22:13:08 +0530 > > > Hello all! > > Version 0.20 is finally here. This milestone supports all the methods > that were planned for in the initial developement viz, > GET > PUT > PROPFIND > PROPPATCH > DELETE > SEARCH > > There may be bugs which we are constantly trying to hunt down. The next > work for us is to document the specifications till this milestone. After > that, we'll move on towards the final part of the coding phase -- > authentication and access control. Then we will be revise the specs and > finally go on to testing. Parallelly, we're trying to put up HTTP forms > with some kind of servlet/php/cgi-bin scripts to populate data for > demonstration. > > I am attaching the internet draft of the specs that we are working on. > SEARCH has not been documented yet but will be done in one or two days. > Please use the latest version of the specs (attached). > > I hope the AIT group keeps us posted on their development of the client > side when the actual work starts. > > Later, > Rushi > |
|
From: Rushi D. <ru...@vs...> - 2002-02-22 16:56:59
|
AIT AIT wrote:
> We have installed the server and it is running properly.But i have
> some doubts
Can you please let me know the platform?
> 1.How will be the authentication for the user be done.
Right now, there is no authentication mechanism. We will be working on
authentication and access control in a few days time. Here's a brief
idea of how it will happen. There are three categories of users that
would want to access the system
a> owner
b> friend
c> guest
The owner can access his data source with an administrative password and
regulr HTTP authentication will follow. Guests are anonymous users (i.e.
users that do not provide any password and hence have the most
restricted access). Friends are people who are known to the owner of the
datasource and who entry has been made in the datasource's address book
(also stored in IMV format using system defined schema). It would be
impractical for storing passwords of the friends, because a user may be
a friend of many users and would have to remember too many passwords
(not to mention administer them). So we could use a public/private key
mechanism. The address book contains an n-tuple (username, datasource
URL, public key) of each friend. The friend attempts to login with HTTP
authentication providing username and datasource URL as password. The
server will start a session and randomly generate a token and present it
back to the user agent (browser). The browser will sign the token with
the friend's private key and send it back to the server. The server will
decode the token to check authenticity and allow the friend in.
This system is dependent on the assumption that all friends have valid
address book entries in a user's datasource before they are allowed access.
Of course, don't worry about authentication/access-control right now. It
is for later.
> 2.How does a user create a datastore from scratch
In the default config datasource for user "amrit" will be stored in
/var/jdbm/amrit. There are no server methods for creating datasources as
this is an admin task that will be done at the server side. Right now
(since there is no auth/a.c mechanism) all you need to do is make the
required directory:
$ mkdir /var/jdbm/amrit
Also /var/jdbm must be read/writeable to the UNIX user running tomcat,
as mentioned in the README.
To help you get started I'm attaching a sample datasource collection.
Place the file in /var/jdbm and unjar it to create the "pavan"
datasource. Then point your browser to:
http://localhost:8080/imv/pavan/28a0c47f-00ec-1000-cb68-cc1c9f8389c7
Note: You may require the latest version of the imv servlet (version
0.20). Get it from sourceforge.
> 3.You had demonstrated us the server by using a ui if you could give
> us that it would be of great help.
Santosh, could you mail it to this list?
Rushi
--
|
|
From: Rushi D. <ru...@vs...> - 2002-02-22 16:56:35
|
Hello all!
Version 0.20 is finally here. This milestone supports all the methods
that were planned for in the initial developement viz,
GET
PUT
PROPFIND
PROPPATCH
DELETE
SEARCH
There may be bugs which we are constantly trying to hunt down. The next
work for us is to document the specifications till this milestone. After
that, we'll move on towards the final part of the coding phase --
authentication and access control. Then we will be revise the specs and
finally go on to testing. Parallelly, we're trying to put up HTTP forms
with some kind of servlet/php/cgi-bin scripts to populate data for
demonstration.
I am attaching the internet draft of the specs that we are working on.
SEARCH has not been documented yet but will be done in one or two days.
Please use the latest version of the specs (attached).
I hope the AIT group keeps us posted on their development of the client
side when the actual work starts.
Later,
Rushi
|
|
From: Rushi D. <ru...@vs...> - 2002-02-22 16:56:31
|
[Prerequiste: At least a casual glance at the examples listed in the IMV
internet draft specs]
We are using two level hierarchy for showing system properties of
attributes in the PROPFIND/SEARCH responses. To keep things simple,
reference is only make at the entity's property (i.e. system prop or
attribute). For example, a PROPFIND may want the attributes...
<prop>
<firstname/>
<lastname/>
</prop>
More often than not, only the value of the attribute is required. But
the current implementation provides all the system properties of the
attribute in the response.
<prop>
<firstname>
<value>Vinod</value>
<type>DataAttribute</type>
<accessRead>45</accessRead>
<timeCreation>25 feb 2002 etc</timeCreation>
blah... blah... blah..
</firstname>
<lastname>
<value>Kulkarni</value>
<type>DataAttribute</type>
<accessRead>45</accessRead>
<timeCreation>25 feb 2002 etc</timeCreation>
blah... blah... blah..
</lastname>
</prop>
In the syntax that we have defined, an IMV-attribute is depicted as an
XML-Element that can contain IMV-Sys-prop XML-Elements which contain
text. Access to attributes can be made only through the entity to which
they belong.
But most of the times, during say a search, the user is only interested
in the value. Currently search responses are polluted with a lot of junk
(unrequired) data in order to maintain the orthogonality of the syntax.
An alternative could be to use only one-level hierarchy. So in IMV
speak, IMV-attributes would be XML-Elements containing text directly
that constitutes to the value.
>> Request
<prop>
<firstname/>
<lastname/>
</prop>
>> Response
<prop>
<firstname>Vinod</firstname>
<lastname>Kulkarni</lastname>
</prop>
If the user is really interested in the attributes properties, he would
have to propfind on the attribute (i.e. on
/imv/mydatasource/00923402-uuid-9403290/firstname), which would return:
<prop>
<value>Vinod</value>
<timeCreation>26 feb 2002..etc</timeCreation>
<accessRead>46</accessRead>
...
</prop>
However, in special cases the user will be interested in the attribute's
properties (esp "mandatory" property of metaAttributes). This could be
solved using...
<prop>
<firstname mandatory="true"/>
<lastname mandatory="false"/>
</prop>
So, which XML presentation should be follow?
Later,
Rushi
|
|
From: Rushi D. <ru...@vs...> - 2002-02-19 18:55:28
|
Hello group;
The AIT project team has joined the mailing list. I have posted the
latest release of the imv servlet on the imv website:
http://sourceforge.net/projects/imv
You can download and test it on your system. You will require
Jakarta-Tomcat-4.0.1 and Java 2 JRE for the binary distribution.
Additionally JDK-1.3.1 and Jakarta-Ant are required for building the
source version. Latest javadocs (which are obviously empty) are also
available. Read the README in the top-level directory of the
binary/source distribution for how to setup/install imv servlet.
Here's a quick guide to installing the required tools.
<text>
1> Grab the latest binary release of Jakarta-Tomcat from:
http://jakarta.apache.org/tomcat
2> Gunzip/untar the distribution to your favourite location (/usr/local/
or D:/java), which will create jakarta-tomcat-4.0.1 directory.
3> Grab the latest binary release of Jakarta-Ant from:
http://jakarta.apache.org/ant
4> Gunzip/untar the distribution to your favourite location (/usr/local/
or D:/java), which will create jakarta-ant-1.4.1 directory.
5> Copy or link the ant shell script invoker to some directory in your
path (/usr/bin, C:\windows)
6> Set up the following variables in your profiles or bashrc
export JAVA_HOME=/usr/local/java # or wherever
export CATALINA_HOME=/usr/local/jakarta-tomcat-4.0.1
export ANT_HOME=/usr/local/jakarta-ant-1.4.1
or in Windows, add to AUTOEXEC.BAT (or WinNT env variables)
set JAVA_HOME=D:\java\jdk1.3 # or wherever
set CATALINA_HOME=D:\java\jakarta-tomcat-4.0.1
set ANT_HOME=D:\java\jakarta-ant-1.4.1
7> Follow instructions in the source/binary release package of imv.
</text>
Also attached is the latest draft of the imv webdav specifications. It
is highly volatile and we are constantly updating it. Most of the
framework won't change. The language/wording requires serious work.
Rushi Desai
|
|
From: Santosh D. <sa...@us...> - 2002-02-19 10:50:55
|
Follow this link >> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/index.html |
|
From: Santosh D. <sa...@us...> - 2002-02-14 08:30:44
|
Hi, A Useful link discussing WebDAV extentions to the WebDAV protocol. Thanks, Santosh |
|
From: Vinod K. <vi...@pe...> - 2002-02-12 06:37:34
|
Guys, Have a look at this. After we have the 'base' infrastructure of each node representing one 'entity' related to some information, we will require some kind of query language that will give us results in a tree like structure. RDF is going to be that structure (+ query language). However, it is bit hard as of now, and I don't want our infrastructure to depend on that. For now, we are going to get only one entity at a time, and for navigation, we are going to use our own model. Second technology that we need to be aware of is "Topic Maps". (Use google to search this.) This is very similar to what we are doing. However, there are some really major differences (Namespaces etc.). You will be able to appreciate these once we are very well aware of pros and cons of our approach. -Vinod |
|
From: Rushi D. <ru...@vs...> - 2002-02-09 04:37:57
|
We already have webspace on sourceforge for putting up any documentation that we produce. I am not aware how twiki works. We *would require* a machine at PSPL, possible for testing the IMV server once it's ready (another 15-20 days). So if you could make a machine available, possibly with and Internet IP address, it would be great. I can install the necessary software on the machine (GNU/Linux, Apache, Tomcat) if you like. How is the work on the Webdav client for Mozilla coming up. We are developing the Webdav protocol mapping for IMV. Basically, very intuitive approach so it won't be difficult to adapt any webdav client to support IMV. Later, Rushi Vinod Kulkarni wrote: > Hello all, > > We should set up some home pages for IMV. One idea is that we should > use twiki for this purpose. So we can contribute in parallel. So I will > have to try find a machine and setup resources for this one. > > -Vinod > > > _______________________________________________ > Imv-devel mailing list > Imv...@li... > https://lists.sourceforge.net/lists/listinfo/imv-devel > |
|
From: Vinod K. <vi...@pe...> - 2002-02-08 05:20:10
|
Hello all, We should set up some home pages for IMV. One idea is that we should use twiki for this purpose. So we can contribute in parallel. So I will have to try find a machine and setup resources for this one. -Vinod |
|
From: <pr...@pe...> - 2002-01-31 16:27:35
|
Please continue to think more on this. We need to be aware <br> that: <br> - IMV interface is not a datastore per-se; it is like a web. So Any information can be added/removed by anybody (especially when you look at aggregated information). <br> <br> So if I have User (Node) + Phone (Attribute), someone <br> may, in their datasource, attach \'HomePhone\' as new attribute and provide a value. A third person, when he does <br> aggregation of that specific user from multiple data sources, he will be able to see all such extra attributes <br> in one place. <br> <br> Whether access is only one entity at a time, or whether it is \'bulk\' is not a issue. We can always request bulk load <br> as specific request. So when I get a particular resource from DAV IMV Server, the resource contents, along with main info, can contain other contents as XML - this is typically <br> the tree structure with this node as root. The depth of the tree can be specified in request etc. <br> <br> So some more finer thinking is required ... <br> <br> -Vinod <br> <br> > Continuing with the feeling that giving attributes full fledge entity <br> > status (i.e. uuid, uri, etc) is unnecessary I would like to present an <br> > alternative way of looking at things: <br> > <br> > We define nodes as units of data containing a set of attributes. So <br> > we could take a clue form this and model as follows: <br> > IMV(DataNode, MetaNode, DataRelation, MetaRelation) => DAV(Collection) <br> > IMV(Attribute) = DAV(Resource). <br> > <br> > Anyway providing means to store \'content\' with a Node (or Relation) is <br> > not really required. I cannot think of scenarios where we would need to <br> > store content with a Node. Most often the content will be wrapped into <br> > some Attribute of the Node. eg> With a person\'s record we might want to <br> > store a picture, but that could be stored in an Attribute \'picture\' <br> > <br> > So here\'s some example: <br> > <br> > <href>http://server/path/to/imv/datasource1/1234</href> <br> > <prop> <br> > <type>DataNode</type> <br> > <timeCreation>23:32:43:12</timeCreation> <br> > ... ( other system properties) ... <br> > </prop> <br> > <br> > To access attributes: <br> > <br> > <href>http://server/path/to/imv/datasource1/1234/phonenumber</href> <br> > <prop> <br> > <type>Attribute</type> <br> > <value>+91-20-565-9001</value> <br> > <timeCreation>23:32:43:12</timeCreation> <br> > ... (other system properties) ... <br> > </prop> <br> > <br> > Hence here\'s a directory like structure <br> > <br> > http://server/path/to/imv/datasource1/9876 <--- <br> > MetaNode for person <br> > http://server/path/to/imv/datasource1/9876/phonenumber <--- MetaAttribute <br> > http://server/path/to/imv/datasource1/1234 <--- <br> > DataNode for \'Rushi\' <br> > http://server/path/to/imv/datasource1/1234/phonenumber <--- DataAttribute <br> > <br> > Finding the \'phonenumber\' of \'Rushi\' is as easy as PROPFINDing <br> > http://server/path/to/imv/datasource1/1234/phonenumber. <br> > <br> > To enlist all attributes of \'Rushi\' just PROPFIND the collection <br> > http://server/path/to/imv/datasource1/1234 with Depth infinity or 1. <br> > <br> > <br> > <br> > <br> > <br> > <br> > <br> > _______________________________________________ <br> > Imv-devel mailing list <br> > Imv...@li... <br> > https://lists.sourceforge.net/lists/listinfo/imv-devel <br> > <br> > <br> |
|
From: Rushi D. <ru...@vs...> - 2002-01-31 16:11:16
|
Continuing with the feeling that giving attributes full fledge entity
status (i.e. uuid, uri, etc) is unnecessary I would like to present an
alternative way of looking at things:
We define nodes as units of data containing a set of attributes. So
we could take a clue form this and model as follows:
IMV(DataNode, MetaNode, DataRelation, MetaRelation) => DAV(Collection)
IMV(Attribute) = DAV(Resource).
Anyway providing means to store 'content' with a Node (or Relation) is
not really required. I cannot think of scenarios where we would need to
store content with a Node. Most often the content will be wrapped into
some Attribute of the Node. eg> With a person's record we might want to
store a picture, but that could be stored in an Attribute 'picture'
So here's some example:
<href>http://server/path/to/imv/datasource1/1234</href>
<prop>
<type>DataNode</type>
<timeCreation>23:32:43:12</timeCreation>
... ( other system properties) ...
</prop>
To access attributes:
<href>http://server/path/to/imv/datasource1/1234/phonenumber</href>
<prop>
<type>Attribute</type>
<value>+91-20-565-9001</value>
<timeCreation>23:32:43:12</timeCreation>
... (other system properties) ...
</prop>
Hence here's a directory like structure
http://server/path/to/imv/datasource1/9876 <---
MetaNode for person
http://server/path/to/imv/datasource1/9876/phonenumber <--- MetaAttribute
http://server/path/to/imv/datasource1/1234 <---
DataNode for 'Rushi'
http://server/path/to/imv/datasource1/1234/phonenumber <--- DataAttribute
Finding the 'phonenumber' of 'Rushi' is as easy as PROPFINDing
http://server/path/to/imv/datasource1/1234/phonenumber.
To enlist all attributes of 'Rushi' just PROPFIND the collection
http://server/path/to/imv/datasource1/1234 with Depth infinity or 1.
|
|
From: Santosh D. <sa...@pr...> - 2002-01-31 05:06:49
|
Hi,
I have attached a sample SEARCH Query.
Thanks,
Santosh
------- Original Message -------
> From: Rushi Desai <ru...@vs...>
> To: "imv...@li..." <imv...@li...>
> Subject: [Imv-devel] Alternative IMV data struct
> Date: Thu, 31 Jan 2002 00:29:32 +0530
>
>
> See attachment
>
> Rushi
> An alternative structure for IMV
> --------------------------------
>
> We have been looking at IMV data source as a collection of 6 types of
> entities. We gave equal importance to nodes and attributes. Attributes
> themselves were entities having their own id, URI, etc. In such case
> attributes need to be differentiated from entity-properties. When IMV is
> converged to DAV this is what happens:
> IMV(Entity property) = DAV(property)
> IMV(Attribute) = DAV(resource)
>
> This is messy. For example let's consider the following:
>
> E1 {
> id : 6788
> type: MetaNode
> value: Person
> }
>
> E2 {
> id: 6789
> type: DataNode
> value: Santosh Dawara
> }
>
> E3 {
> id: 6790
> type: MetaAttribute
> value: Phone number
> }
>
> E4 {
> id: 6791
> type: DataAttribute
> value: 5678900
> }
>
>
> Now "PROPFIND /path/to/ds1/6789 HTTP/1.1" would produce the following XML
> response:
>
> ...
> <prop>
> <id>6790</id>
> <type>DataNode</type>
> <6790>6791</6790>
> </prop>
>
> This would be followed by a "PROPFIND /path/to/ds1/6791 HTTP/1.1" to get the
> <value/> of phonenumber. I think this is messy.
>
> The question is do we actually require Attributes to have full entity status
> (i.e. have their own id, uri etc) and map them as resources? Also note that
> '6790' and '6791' are meaningless until the are GOT or PROPFOUND. Here's a
> suggestion.
>
> We merge the concept of MetaAttribute and DataAttribute such that they
> become nothing but DAV properties. So a resource 6788 (a MetaNode) would have
> a set of 'system properties' (eg, id, type, uri, contentType...etc) as well
> as a set of user-defined 'properties' (eg, PhoneNumber, FirstName,
> LastName). A resource 6789 which is an instance of 6788 would also have
> these properties (Phonenumber, FirstName, LastName...etc) with value being
> the 'system properties' of the dataattribute (eg. id, type, uri,
> contentType...etc). Here's a more full example to give you some idea.
>
>
> Note 9876 is a MetaNode modelling 'book' and 1234 is an instance of 9876
> a book on Java programming.
>
> >> Request
>
> PROPFIND /path/to/imv/ds1/1234 HTTP/1.1
> Host: myhost
> Content-Type: text/xml
> Content-length: xxx
>
> <?xml version="1.0" encoding="utf-8">
> <D:propfind xmlns:D="DAV:">
> <D:allprop/>
> </D:propfind>
>
> >> Response
>
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml
> Content-Length: xxx
>
> <?xml version="1.0" encoding="utf-8">
> <D:multistatus xmlns:D="DAV:">
> <D:response>
> <D:href>http://myhost/path/to/imv/ds1/1234</D:href>
> <D:propstat>
> <D:prop xmlns:I="IMV:"
> xmlns:R="http://myhost/path/to/imv/ds1/9876">
> <I:id>1234</I:id>
> <I:type>DataNode</I:type>
> <I:value>The Complete Reference Java 2</I:value>
> <I:timeCreation>UTC-2001-23-22-12-33-32-2</I:timeCreation>
> ...
> <R:title>
> <I:value>The Complete Reference Java 2</I:value>
> <I:timeCreation>UTC---</I:timeCreation>
> ...
> </R:title>
> <R:author>
> <I:value>Peter Naughton</I:value>
> <I:timeCreation>UTC---</I:timeCreation>
> ...
> </R:author>
> </D:prop>
> <D:status>HTTP/1.1 200 OK</D:status>
> </D:propstat>
> </D:response>
> </D:multistatus>
>
>
>
> Further, if explicit reference is to be made to an attribute, here's how:
>
> PROPFIND /path/to/ds1/9876/title HTTP/1.1 <--- Prop reference (previously
> called MetaAttribute)
> GET /path/to/ds1/1234/pdf_file HTTP/1.1 <--- Prop reference (previously
> called DataAttribute)
> PROPFIND /path/to/ds1/1234/author HTTP/1.1
>
>
|
|
From: Rushi D. <ru...@vs...> - 2002-01-30 18:56:37
|
See attachment Rushi |
1 message has been excluded from this view by a project administrator.